The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Werner Schuster on Nov 07, 2008
Static analysis tools allow to keep code quality up and warn of potential bugs. Compilers in statically compiled languages often run static analysis checks and report potential problems as warnings. Popular stand-alone tools are C's lint or Smalltalk Lint, many modern IDEs also perform static analysis on code, often incrementally as code is edited.
Static analysis tools for Ruby for a long time suffered from the lack of a standard way of accessing the Abstract Syntax Tree (AST) of Ruby source. One solution was the ParseTree gem, which uses a native extension to access the parse tree of parsed Ruby code. One problem of ParseTree include the dependency on native code to run. ParseTree is also only available on Ruby 1.8, but is unlikely to be supported on 1.9 (Ruby 1.9 comes with Ripper, a library that allows to parse source files but not access the parse trees at runtime). The ParseTree support across new Ruby implementations is inconsistent at the moment.
The introduction of ruby_parser, a Ruby parser written in Ruby promises to fix these problems. The project was recently released in 2.0 version, which improved performance and, importantly, added line numbers as metadata to the ASTs. The latter information is crucial for static analysis tools as they need to report the location of a discovered problem.
An important point, considering that all current Ruby IDEs written either in Java (Eclipse based IDEs such as Aptana or 3rdRail, Netbeans' Ruby support, JetBrains' RubyMine) or .NET (Ruby In Steel, based on VS). All of these IDEs also feature static analysis code of Ruby code, but none of it is written in Ruby. Static analysis code based on a Java or .NET based Ruby parser and AST obviously doesn't run on MRI or other Ruby implementations. UnifiedRuby is a cleaned up version of ParseTree's output, and in combination with ruby_parser, it's now possible to parse Ruby source code and analyze in pure Ruby.
A growing list of static analysis tools has become available in the past few months.
Flay, written by Ryan Davis, checks codebases for duplicates. By using an AST, instead of the source code, it's possible to compare the code structurally. Copy/pasted code can so be detected even if, say, literal values were modified. Ryan has previously released another static analysis tool flog, which calculates a score for a codebase which depends on various patterns considered bad, eg. large numbers of dependencies. Both flay and flog can be used from the command line to check code bases. Flay uses ruby_parser to parse Ruby code.
Reek by Kevin Rutherford is a "a code smells detector for ruby". It comes with a list of checks which detect long method bodies, large classes, bad names, etc. The checks are written as SexpProcessor subclasses, which works as a visitor over the AST. Reek's code is hosted at Github.
Roodi is similar to reek in that it allows to run a list of checks over a codebase. Roodi comes with checks that ensure methods or modules comply with a naming convention, max parameter count, etc. Other checks include advice such as avoiding for loops, etc. The shipped checks can also be easily configured with a YAML file. New checks can be easily written as well. A checker class registers the types of AST nodes it's interested in and can then handle the matched subtrees.
Rufus by John Mettraux allows to check Ruby for unwanted or unsafe code. The Rufus library allows to check some Ruby source code before loading it. Eg. loading a Ruby file that consists of a single line like exit is probably a bad idea. The library can be configured with custom patterns of code to be excluded.
Do you plan to add one or more of these tools to your continuous integration setup? What checks would you like to see or write?
A practical guide to choosing the right agile tools
Monitor your Production Java App - includes JMX! Low Overhead - Free download
You might also want to check out RubyDiff as another static analysis tool. It doesn't check code style, but does a syntactic diff on ruby code.
There is a rubyforge project, and the source is available on github.
Hi Werner,
thanks for the link to "rufus-treechecker". "rufus" is in fact a set of ruby gems derived from ruote.
The less obscure of these gems is rufus-scheduler, for scheduling pieces of ruby code in an 'at' or 'cron' fashion.
Best regards.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
2 comments
Watch Thread Reply