Linting the hell out of your Ruby classes with Pelusa

Written in Development by Txus Bach — February 14, 2012

As you might know, yesterday morning we had Monday talks at the office! Oriol talked about Object Oriented Nirvana, inspired by an old post about how to improve Object Oriented skills by using certain constraints while you're coding.

Then I got immediately interested on how to automate this, and knowing how easy is dealing with the Rubinius' Abstract Syntax Tree, I decided to give it a try and develop a tool that statically analyzes Ruby code to gain insights from it.

But what does it mean "statical analysis"? It means that this tool won't run any of your code at all, it just inspects it like you would as a developer, by looking at it. Since code is nothing more than nodes inside nodes, you can easily identify certain patterns that you consider wrong or desirable (for example, having else clauses in ifs, nesting blocks, or just using the word "foo" in actual programs). By traversing the AST, you can analyze parts of the code that don't fit your particular style or code quality requirements (actually with a little more work you could programmatically change those parts, i.e. automatic refactoring). I find this really cool!

The tool I've been working for the last couple of days is something along these lines (excluding, for now, the automatic refactoring part).

Introducing Pelusa - a Ruby Lint to improve your OO skills

Pelusa (which is Spanish for the word lint) is a static analysis tool and framework to inspect your code style and notify you about possible red flags or missing best practices. Above all pelusa doesn't run your code -- it just analyzes it syntactically to gain superficial insights about it, and raise red flags when needed.

Although Pelusa needs Rubinius to run, due to how easy it is to work with a Ruby AST with it, it doesn't mean that you have to run your application or Ruby code on Rubinius. Since it's a static analysis tool, pelusa doesn't care what your code runs on, it just looks at it and tells you stuff.

If you're curious, it looks like this (running on it's own code base, oh inception):

Find the default lint checks too Taliban for your tastes?

These are just guides, so you're free to fork the project and add/remove lints as you like. The fact that I've started with those doesn't mean that any of us thinks these are the true and only practices of Object Orientation, it's just a set of constraints that are fun to follow to achieve a mindset shift in the long run, or just to explore new styles.

One of the next features will be easy composability of lints, so you can remove those you don't like and add custom ones that fit your team's style or quality standards :)

Pelusa as a static analysis framework

With Pelusa, writing your own lints becomes very easy. Check out some of the default lints under the lib/pelusa/lint/ directory in the Github repo. Rolling your own style has never been easier!

Conclusion

My point by doing this was mainly exploring static analysis with Ruby, since I've never done it before, but also proving a point: good development tools are not only for statically typed languages! With a little imagination we can leverage our skills to make life better, or at least more interesting, for Ruby developers as well.

What do you think? Would you use this kind of tooling in your everyday job?

View all posts tagged as