静的解析ツールの総まとめ：Roodi、Rufus、Reek、Flay

作者 Werner Schuster , 翻訳者 編集部 投稿日 2008年11月21日

セクション

設計/アーキテクチャ,

デベロップメント

トピック

Ruby ,

動的言語 ,

言語 ,

プログラミング ,

Static Analysis ,

ParseTree

共有 |

静的解析ツールを使えばコード品質の維持と潜在的なバグの通知が可能になる。静的にコンパイルされた言語のコンパイラでは、静的解析チェックが実行されることが多く、潜在的な問題を警告として報告する。人気の高いスタンドアロン型のツールとしてはCのlintやSmalltalk(リンク)があり、多数の最新IDEでもコードに静的解析を実行するが、コード編集時に付加的に行うことが多い。

Ruby向けの静的解析ツールは、Rubyソースの抽象構文ツリー（AST）への標準的なアクセス方法がなかったために、長い間そのあおりを受けてきた。解決策の１つ、ParseTreeジェムは(参考記事・英語)ネイティブの拡張を使って、パースされたRubyコードのパースツリーにアクセスする。ParseTreeの問題の1つに、実行がネイティブコードに依存することが挙げられる。さらにParseTreeはRuby 1.8上でのみ利用可能で、1.9ではサポートされない可能性が高い（Ruby 1.9にはライブラリのRipperが付属するが、Ripperはソースファイルをパースできるが、ランタイムにパースツリーへのアクセスはできない）。ParseTreeが新しいRuby実装の全体にわたってサポートされるかは、今のところ一貫していない。

Rubyで記述されたRubyのパーサー(参考記事・英語)、ruby_parserを導入すれば、こうした問題は解決する見込みだ。このプロジェクトは先日バージョン2.0がリリースされたが(参考記事・英語)、パフォーマンスが改善され、重要点として、ASTへのメタデータとして行番号が追加された。発見した問題の所在地を報告する必要があるため、行番号情報は静的解析ツールに極めて重要である。
重要なポイントは、現在のすべてのRuby IDEを記述している言語が、Java（Aptanaや3rdRailなどのEclipseベースのIDE、NetbeansのRubyサポート、JetBrainsのRubyMine(リンク)）あるいは.NET（VSベースのRuby In Steel）であることだ。これらすべてのIDEもRubyコードの静的解析コード機能を備えているが、Rubyで記述されているものは皆無である。Javaベースの静的解析コードや.NETベースのRubyパーサーとASTが、MRIや他のRuby実装で動作しないことは明白である。ParseTreeの出力をクリーンアップしたバージョンがUnifiedRubyで、ruby_parserと組み合わせて使えば、Rubyのソースコードのパースと純粋なRubyでの解析が可能になる。

ここ数ヵ月間で、多数の静的解析ツールが利用可能になった。

Ryan Davis氏によるFlay(リンク)は、コードベース内の重複をチェックする。ソースコードの代わりにASTを使うことにより、構造的にコードを比較できる。たとえばリテラル値が修正されていても、コピーやペーストしたコードを検知可能だ。Davis氏は以前、別の静的解析ツールのflogをリリースしており、flogでは様々な不適当なパターン（たとえば多数の依存性）に依存するコードベースのスコアを計算する。flayとflogは両方ともコマンドラインからコードベースのチェックができる。flayではRubyコードのパースにruby_parserを使っている。

Kevin Rutherford氏によるReekは(リンク)「Rubyのためのコードスメル(リンク)（編集部注：より深部に存在する問題を指し示している可能性のある、プログラムのソースコードに見られる徴候のこと（Wikipediaより：http://en.wikipedia.org/wiki/Code_smell））検知器」である。Reekには、長いメソッドボディや大きなクラス、望ましくない名前などを検知するリストがついてくる。このチェックはSexpProcessorのサブクラスとして書かれており、AST上のビジターとして機能する。ReekのコードはGithubで提供されている(リンク)。

Roodi(リンク)は、コードベース上でチェックリストを動作させるという点でReekに似ている。Roodiには、メソッドやモジュールが命名規則や最大パラメータ数などに確実に準拠するよう計らうチェックがついてくる。その他のチェックには、ループの回避などを目的としたアドバイスが含まれる。送られたチェックはYAMLファイルでも容易に設定できる。新しいチェックの記述も簡単である。チェッカークラスを使って知りたいASTノードの型を登録すると、そのチェッカークラスでマッチするサブツリーを処理できるようになる。

John Mettraux氏によるRufusは(リンク)、望ましくないコードや安全でないコードをチェックする。Rufusのライブラリを使って、Rubyのソースコードをロードする前にチェックできる。たとえば、exitのような一行構成のRubyファイルをロードしようという考えは、おそらく望ましくないだろう。このライブラリでは、除外するコードのカスタムパターンを設定できる。

みなさんは、継続的な統合の準備としてこうしたツールを１つ以上追加する予定があるだろうか。調べてみたいチェックや、記述したいチェックはあるだろうか。

原文はこちらです：http://www.infoq.com/news/2008/11/static-analysis-tool-roundup