Gruntのpluginでgrunt-platoというのがあって、Platoを使ってJavascriptの静的解析結果をvisualizeしてレポートしてくれます。
レポートのサンプルがいくつか載っていて、jQueryのサンプルはこんな感じ。解析は主にphilbooth/complexityReport.jsを使ったcomplexityの解析結果で、Platoはそれをグラフに出力してくれる。あとJSHintでの検知結果もついてくる。
complexityReport.jsでは何を出力してくれるかというと、lines of code、number of parameters、cyclomatic complexity、Halstead metrics、maintainability indexなど。サンプルがこんな感じ。
Platoのグラフで注目されるのは、Maintainabilityという項目かなと思われますが、Maintainabilityの項目は、Maintainability Index Range and Meaning - Code Analysis Team Blog - Site Home - MSDN BlogsとかMaintainability - Wikipedia, the free encyclopedia、Virtual Machinery - Sidebar 4 - MI and MINC - Maintainability Indexに詳しく書かれている。コードの複雑性を評価することで、維持しやすい状態を保つ指標になる、と思われる。msdnのコード メトリックス値で類似する内容が日本語で読める。
Maintainabilityの計算方法は下記のようになっている。
1 | 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code) |
係数がなぜこの値なのかは、勉強不足ゆえ不明…
Maintainability Index は、この値を0から100までの数値に変換したもの。microsoftのサイトでは、20-100までの間はnoiseレベルのものと見なして、0-20になるようなら注意しないといけないということにしている。
1 | Maintainability Index = |
それぞれの値ですけど、Halstead VolumeはHalstead complexity measures - Wikipedia, the free encyclopediaに書いてあるVolumeのこと。オペレーターとオペランドの、のべ数に、オペレーターとオペランドのユニーク数の対数を乗算して得る。処理の数が多ければ多いほどMaintainabilityは下がるし、処理の種類が多くなればMaintainabilityはより簡単に下がる、と。自然対数で処理されるので、10個から100個に変わるのと、1000個から1100個に変わるのでは、Maintainabilityへの影響は前者の方が大きい。
Lines of CodeはLOC - Wikipediaを参照。physicalかlogicalかについての明記は見つかりませんでしたけど、logicalだと思います。とりあえずcomplexityReport.jsではlogicalを使っている様子。ソースの（論理）行数が増えれば増えるほど、Maintainabilityは下がると。自然対数で処理されるので、10行から100行に変わるのと、1000行から1100行に変わるのでは、Maintainabilityへの影響は前者の方が圧倒的に大きい。
Cyclomatic ComplexityはCyclomatic comlexity - メモログにメモしました。処理経路の数が多ければ多いほど、Maintainabilityは下がると。
Cyclomatic comlexityは自然対数で処理しないので、増えれば増えるほどリニアにMaintainabilityは下がっていく。けれども係数が小さいので、モジュール単位とかでMaintainabilityを計測すると大勢に影響しないほど小さい感がある。モジュール単位での計測だと、コードの行数が係数が大きくて、行数も100から1000くらいだろうから、増えた時の影響力も大きい感があります。Halstead Volumeも比較的影響力大きいかな。
では根本としてどの範囲を対象に計測するのが妥当なのかという別の疑問が出てくるわけですが、よく分からない… モジュール内で処理が完結しているならモジュール単位で計算するのが妥当かなあ。
というメモ。