.NET Tools プログラムを仕上げるときの強力な助っ人DevPartner （株）ピーデー　川俣 晶 2003/12/06
Page1 Page2 Page3 Page4

ソース・コードの弱点を検出する「静的ソース・コード解析」

　ソース・コードには、良いソース・コードと、良くないソース・コードがある。要求された機能を実現できていないソース・コードは、もちろん良いソース・コードとはいえない。しかし、要求された機能をすべて実現していて、あらゆるテストを突破する安定性を備えていても、それが良くないソース・コードであると判断される場合がある。

　それはなぜか？

　ソース・コードには、明らかに悪い結果をもたらす書き方というものがある。それは、実行したときに正しい結果を出せるか否かという問題ではない。ソース・コードは、書き終えたらそれで終わりということはなく、バグ取りのためにそれを見ることもあるし、仕様変更で書き換えられることもある。それらの効率を意識せず、ただ動けばよいという態度で取り組むと、最初は速く仕事が進んだように見えても、後で多大な時間の無駄を発生させることになる。また、潜在的に入り込むバグの数にも影響することが考えられる。

　そのような状況に対応するために、いろいろなことが行われている。プログラム言語の進化では、好ましくない書き方（経験的にトラブルの元になるとされる書き方）をそもそも言語仕様違反としてしまう場合がある。例えば、C#では、多条件分岐を行うswitch文の中で、次のcaseラベルに直接処理が進むようなプログラムを言語仕様として禁止している（それぞれに必ずbreak文が必要となる）。これは、C／C++などでバグを生みやすいとされていたコードを禁止してしまった例といえるだろう。

　言語仕様で禁止されていないとしても、コンパイラが検出して、警告（warning）として出す場合もある。例えば、使用されていないローカル変数があると警告を出すコンパイラは多いが、これも、使われない変数があるとソース・コードを誤解する危険があるという状況に対応するものといえる。

　だが、言語仕様やコンパイラが対応しているものだけが、そのような好ましくない書き方のすべてではない。実際にはもっと多くの好ましくない書き方があり、それに対する経験則が存在する。では、それらを言語仕様やコンパイラに組み込めばもっとプログラム開発がスムーズにいくかというと、そういうわけでもない。なぜなら、それらは必ずしも常に適用することが正しいともいい切れないためである。

　例えば、ある書き方が好ましくないとしても、さまざまな事情からそう書かねばならない状況に陥る場合もある。また、好ましい、好ましくないという判断が、人やコーディングの流儀によって分かれる場合もある。そのほか、より詳しいソース・コードのチェックは、コンパイル時間を長引かせることにもなる。ソース修正、コンパイル、実行を繰り返す場合は、コンパイル時間が延びることは効率低下に直結する。それらの事情から考えれば、言語仕様に含まれない判断を一律に行うことは、あまり良いことではない。しかし、それらの判断を一切行わない、というのも同様に良いことではない。それらの判断の中に、有益な情報が含まれる場合もあるからだ。

　そのような、言語仕様やコンパイラのレベルを超えたソース・コードの書き方のチェックを行うのが、DevPartnerの「静的ソース・コード解析」である。

　この機能の使い方は、まったく難しくない。実際に簡単なサンプル・コードを題材にして使ってみよう。ここでは、VB.NETのコンソール・アプリケーションのテンプレートで新規プロジェクトを作成し、以下のようなソース・コードを入力してみた。

Module Module1 Sub Main()     Dim a As Integer     Console.WriteLine(a)   End Sub End Module

「静的ソース・コード解析」に使用するVB.NETのサンプル・コード

　では、このサンプル・コードに、静的ソース・コード解析を行ってみよう。

　DevPartnerをインストールしていると、VS.NETの［ツール］メニューに［DevPartner］というメニュー項目が増える。この項目にはさらに多くのサブ・メニューがある。この中に、［CodeReviewの実行］という項目があるので、それを選ぶと以下のようなダイアログ・ボックスが出てくる。

静的ソース・コード解析を開始するための「CodeReviewの実行」

画面からも分かるように、解析のための「ルール」は全部で562個用意されている。［レビューの開始］ボタンをクリックすると、これらのルールを基にソース・コードが解析される。

　ここでは選択できるものをすべて選択して実行させてみよう。

　［レビューの開始］ボタンを選んで実行すると、しばらく解析処理が行われた後で、結果がVS.NET内で次の画面のように表示される。まず、最初の［サマリ］タブは静的ソース・コード解析処理の要約である。どのような重要度の問題がどの程度の数検出されたかが表にまとめられる。

静的ソース・コード解析の処理結果の要約を表示する［サマリ］タブ

　次の［問題］タブでは、具体的な問題点がリストされる。ここでは、初期化されていない変数が問題にされている。VB.NETは変数が必ず初期化される言語仕様なので、明示的に初期化しなくてもあいまいさはない。しかし、明示的な初期化は行った方がよい、という考え方があるということである。

具体的な問題点がリスト表示される［問題］タブ

ここでは初期化されていない変数が問題となっている。VB.NETでは、変数を明示的に初期化しなくてもよいが、明示的な初期化は行った方がよいというアドバイスが得られる。

　次の［ネーミング］タブは、ネーミング（名前付け）に関する問題点がリストされる。ここでは、変数「a」が好ましくなく、「intA」という名前にしてはどうかという提案がなされている。変数名はデータ型が分かるような文字列を付け加えた方がよい、という考え方が見て取れる。

ネーミング（名前付け）に関する問題点がリスト表示される［ネーミング］タブ

ここでは、変数「a」が好ましくなく、「intA」という名前にしてはどうかという提案がなされている。

　次の［メトリクス］タブは、メトリクスについての情報が表示される。メトリクスとは複雑度や不良修正の確率などを数値化したもので、そのリストが表示される。

コードのメトリクスをリスト表示する［メトリクス］タブ

メトリクスとは複雑度や不良修正の確率などを数値化したもので、そのリストが表示される。

　これらの情報が示すものは、プログラムが動作する、しないという次元とはやや異なるものである。これを生かすかどうかはプログラマー次第である。まったく無視することは好ましい態度ではない。しかし、適用しているルールが自分の必要とする条件と必ずしも一致しないという場合はあり得るだろう。その場合は、ルールを自分でカスタマイズすることができる。VS.NETのメニューから、［ツール］−［DevPartner］−［CodeReviewルールの管理］と選ぶと、「CodeReviewルール・マネージャ」が開く。

ルールをカスタマイズするための「CodeReviewルール・マネージャ」

静的ソース・コード解析で利用するルールの詳細をチェックし、適用するかどうかを設定できる。

　これを使って、不適切なルールのチェックを外し、必要なルールを有効にすることができる。静的ソース・コード解析は、このCodeReviewルール・マネージャがあって、初めて実用の道具になるといえるだろう。

INDEX
	［.NET Tools］
	プログラムを仕上げるときの強力な助っ人DevPartner
	1．分析を支援するDevPartner
	2．ソース・コードの弱点を検出する「静的ソース・コード解析」
	3．処理にかかった時間を計測する「パフォーマンス分析」
	4．テスト漏れを防止する「カバレッジ分析」

「.NET Tools」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）