(Bill Sheldon)

 今回は「FxCop」を紹介しよう。これはコードを分析して.NETの規約に準拠しているかどうかを自動的に調べるツールで,Microsoftが開発したものだ。同社が運営するGotDotNetのWebサイトから入手できる(該当サイト)。

 最近FxCopは,多くの関心と支持を得るようになってきた。何人かの開発者はこのツールが好きで,その出力結果を福音のように受け入れている。しかし,私はまだそれほどまでには好きになったわけではない。

 その理由は技術的な問題ではなく,ツールが出すアドバイスを無条件に受け入れることには賛成しかねるからだ。私はプログラミングの標準規約を適用することに反対はしない。FxCopが適用する標準をカスタマイズできるようになっていることには好ましく思っている。コーディングの標準はコードのメンテナンスを容易にするだけではない。エラーも減らすし,FxCopのような自動チェック・ツールは,そうした標準規約をより簡単に実装できるようにしてくれる。

 しかし,私は10年以上前に,同じようなツールを経験しているのだ。その昔,私が働いていた会社は,コードを調べるための自動チェック・ツールを売っていた。今となっては時代遅れなプログラム言語が対象だったが,それは一応うまく動いた。けれども,いくつかの問題があった。私のその時の経験を基に,FxCopのよい点と悪い点を見ていこう。

コンパイル後のアセンブリがチェック対象
 FxCopはカスタマイズ可能なルール・セットを備えている。そのルールは少々分かりにくいが,非常に強力なエンジンによって適用される。コード分析エンジンに限っていえば,FxCopは同種製品で最高のものだ。

 実際,Microsoftも社内でこのエンジンを使っている。ルールについていえば,「ドッグ・フーディング」(ドッグ・フードを食べること)に時間をかければ,よりよくなっていくだろう。すべてのソフトウエアはバグや設計上の問題を抱えている。ドッグ・フーディングとは,自社製品のソフトウエアがどのくらいうまく動くかを知るために,自社でその未完成のソフトを使い込むことである。Microsoftの社員はいつも同社のアプリケーションのベータ版を使っている。正式なリリースの前に徹底的にテストするためだ。FxCopはプログラム開発向けのツールで,Microsoft社内でたくさん利用されている。

 昔,自動標準チェッカは単独でソース・コードをチェックしていた。その結果,ほとんどの標準チェッカはソース・コード内の問題を見つけることを主眼としていた。FxCopは,ソース・ファイルではなく,コンパイルされた.NETのアセンブリをチェックする点で,ほかの標準チェッカとは異なる。このアプローチには長所と短所がある。

 長所は,ソース・ファイルではなく,そのアセンブリをチェックするので,.NET開発者はVisual C#.NET,Visual Basic.NET, Visual C++.NETのアセンブリを,1つのツールで扱えることだ。Microsoftの開発者は各言語の文法に合わせてルール・セットを作る必要がなく,FxCop1つだけで済み,ツールを開発するのに必要な時間とコストを削減できることになる。さらにFxCopはアセンブリを対象にしているので,実行環境に存在する問題を発見できる。別のいい方をすると,スペリングの間違いだけを探すのではないということだ。それは例えば,メモリー管理やセキュリティに関連する問題のような,もっとたくさんの重大な問題を発見する。こうしたタイプのチェックを容易に実行できるように,FxCopはルール・セットをカスタマイズできるように作られている。FxCopのエンジンがアセンブリを評価するときに使う個々のルールを,インポートしたり,有効/無効にしたりできるのである。

 短所は,FxCopがソース・コードではなくコンパイル済みのコードを対象に動作するために,発見した問題がソース・コード上のどこにあるのかをピンポイントで指摘できないことである。FxCopは多くの場合に,問題があるソース・ファイルは指摘するものの,そのソース・ファイルのどこに問題があるのかまでは指摘しない。さらにFxCopは対象の実行ファイルしかロードしないので,ソース・ファイルがどこにあるのかも分からないかもしれない。その結果,FxCopがプロジェクトのソース・ファイルへのリンクを出力しようとする場合,そのプロジェクトがデフォルトの場所,つまりMy Documents\Visual Studio Projectsディレクトリにあるものとする。ところが,多くの開発者はもう少し複雑なディレクトリ構成を使っている。FxCopは問題点を解説したページへの有益なリンクも持っているが,問題の発見と解決は開発者に任せられている。こうした状況は,今後このツールがVisual Studio .NETと統合され,拡張されれば変わることだろう。

 多くの自動標準チェッカと同様に,FxCopは名付け規則に関しては野心的だ。私は自分のコードでは,ローカル変数と関数の引数名には首尾一貫してハンガリアン記法を使っている。Microsoftの.NETの名付け規則の中には,ハンガリアン記法は.NETプロジェクト内では使うべきではないという文章がある(該当サイト)。そのため私のコードに対してFxCopを使うと,多くの「エラー」が表示される。実際はそれらはエラーではなく,どちらかといえば規則への不適合だ。

 Microsoftがハンガリアン記法を許すように,FxCopのデフォルト・ルールを変えるとは期待していない。私がいいたいのは,FxCopやそのほかの自動標準チェッカを使う場合は,あなたのコードにとって何が最適かという点に関して,他人の意見に従うことが不可欠になる。そのツールが出したアドバイスを自分がどう実装するかをよくよく考える準備をしておくことだ。

アドバイスを盲目的に適用するのは危険
 あなたのコードを実際にメンテナンスする手助けをするわけではないのに,ツールが出すアドバイスを盲目的に適用すると,その問題は解決するかもしれないが,同じくらい別の問題を引き起こす可能性がある。実際の例を見てみよう。

 先ほど述べたように,私は以前,標準チェッカを使っていた。私は百万行以上に及ぶシステムを開発しているときに,ほかの開発者が担当する関数領域と名前の衝突を起こさないようにするため,厳格な名付け規則に従わなければならなかった。しかし,システムのほかの部分とデータを交換する際には,そのデータの転送元の名前空間によってそれを追跡した。そのデータを転送元に返す場合には特にそうだ。というのは,データの転送元の名前空間にデータを返す前に,そのデータを絶対に変更しないようにしたかったからである。

 われわれが自動標準チェッカをそのプロジェクトに持ち込んだときには,そのシステムは既に何年もの間使われていて,われわれの名前空間を認識できるようにプログラムされていた。そのチェッカは,例えばループの制御変数名に「i」を使った領域に,フラグを立てることがよくあった。もちろん「i」が名前空間と結び付けられていなかったからだ。この標準チェッカは,われわれのソース・ファイル内の変数に,故意にほかの関数の接頭辞を使った領域にもフラグを立てた。そのため,先に書いたようなデータを追跡できた。

 われわれはこのツールを長年使っていたので,これらのフラグをノイズとして認識していたが,マネージャにはその標準チェッカが出した結果のノイズと実際の問題の違いを理解できなかった。名前空間に関するフラグはノイズというカテゴリに分類されることが多い。しかし「問題」の数を50%は減らしたいと思っているマネージャにとっては,そういうものがメイン・ターゲットになるのだ。

 そこでそのマネージャは,ループ制御変数「i」などの変数名を変える仕事を,経験の浅い開発者にやらせた。こうした変更の実装とテスト作業に同社は余分なコストを費やした。このマネージャは経験の浅い開発者に,ほかの領域の接頭辞を持つ変数の名前も変えさせた。それはその会社にさらにもっと多くの費用を払わせることになった。

 ほぼ1年後に,次のリリースの時期がきた。今度のリリースは何人か新しく雇った開発者に任された。この開発者たちは,彼らの名前空間内にある変数に,実はほかの関数のプロパティが格納されていることを知らなかった。想像がつくと思うが,その混乱はさらに新しい追加コストが発生する結果になった。

 私を責めないでほしい。自動標準チェッカを使ったのは間違いではなかった。それは本物のエラーも見つけた。ノイズの多くをきちんと説明できる経験を積んだわれわれや聞く耳を持ったマネージャたちは,そのプロジェクトの大部分を不必要に変更しなかった。さらにわれわれはその標準チェッカの開発者に対して,自分たちが経験したノイズのいくつかについて伝えたので,その自動ツールのその後のリリースでは対応してくれた。

 同じようにFxCopもノイズをレポートすることがある。FxCopはまだバージョン1.3で,今も開発中であり,Microsoftもこのツールがもっと使いものになるようにそれを拡張し続けている。

 結論としては,FxCopやほかのどんな自動標準チェッカが出すアドバイスも,そのまま盲目的に受け入れてはいけないということだ。そんなことをしたら,自分のコードを不必要に書き換えて,時間とお金を浪費させることになるかもしれない。FxCopの目標は,コードの中にある問題にすべき事柄に関したレポートを出すツールを提供することだと,Microsoftはいっている。合理的な理由のあるそれぞれの潜在的な問題には信頼性のレベルが付けられている。この自動チェッカは経験を積んだ開発者が認識できるようなことをすべて判断できるというわけではない。

Visual Studio 2005と同Express Editionのこと
 最後にレドモンド(米Microsoftの本社)からの最大の話題についてお知らせしておこう。「Visual Studio 2005」(開発コード名Whidbey)のベータ1がリリースされた(既報)。これにはVisual Studio 2005のフル機能が実装されており,先に公開された6つの「Visual Studio 2005 Express Edition」のベータ1と同等の機能が利用できる(既報)。

 Express Editionは特定用途に向けた,Visual Studio 2005のサブセットである。例えば,SQL Server 2005 Express EditionはMicrosoft SQL Server Desktop Engine(MSDE)をベースにしており,データベース機能を提供する。SQL Server 2005 Express Editionは無償で,ほかの5つの低価格のExpressパッケージと連携しており,Web開発またはデスクトップ開発のどちらか一方を対象としている。

 Web開発用にはVisual Web Developer 2005 Express Editionが用意されている。これは,複数のプログラム言語を扱えるツールで,WebアプリケーションやXML Webサービスを開発できる。もう一方のデスクトップ開発については,各.NET対応言語ごとに異なるExpressパッケージがある。Web開発と違って,デスクトップ開発向けのExpressパッケージでは,どれか1つの言語しか使えない。

 多分ご存知だと思うが,Visual Studio 2005は.NET Framework 2.0をベースに作られている。そのうち.NET Frameworkの新バージョンについてご紹介するつもりだ。Visual Studio 2005ベータ1がリリースされたということは,.NET Framework 2.0が1年以内に出荷されることを意味する。