FxCopとStyleCop まとめ

「ADO.netのDataSetをLINQableに書くために (前段)」で書きましたが、「コンパイル(等)のタイミングで、指定したルールに適合していない場合はエラーや警告を出す」、コードの静的解析ツールとして、「FxCop」と「StyleCop」があります。

それぞれよく似た機能を持っているので混同されがちですが、何をしたいかによってどちらを選択するか、あるいは両方使うかが変わってくると思います。

なので、まずはそれぞれどのような特徴を持つのかをまとめてみました。

	FxCop	StyleCop
目的	アセンブリが「クラスライブラリのデザインガイドライン」に適合し、利用者から見てAPIに一貫性と使いやすさが備わっているかを分析する。	ソースコードが一定のルールに基づいて、統一的な記述がなされているかを分析する。（空白や改行の入れ方、括弧の位置、記述の順番など）
分析対象	アセンブリ（IL:中間言語）	C# ソースコード
VisualStudioバンドル	Premium/Ultimate	なし
VisualStudio統合	Premium/Ultimateはビルド統合済み。 Standardは別途ツールをインストールすることで呼び出し可能になる。 Expressでは基本的にFxCopを単体で稼働させる。	Standard以上で可能。ただし、すべてのエディションでcsprojファイルの編集により、ビルドプロセス統合は可能。
カスタムルールの作成	可能	可能

つまるところ、FxCopは「ほかのアセンブリから呼び出されるアセンブリが、使いやすいものになっているか」どうかを分析し、使いにくいと思われる部分を警告を出して修正を促します。FxCopに怒られたところを直すと、確かに使いやすくなっているような気がします。

それに対してStyleCopは、「C#ソースコードが個々人によって差異が発生しないようにする」ために分析し、統一ルールからはみ出た表記には警告を出して修正を促します。

また、FxCopはアセンブリを対象に分析するため、言語はC#でもVB.netでもその他でもなんでもイケますが、StyleCopはソースコードが対象であり、C#に限定される。という違いもあります。

使ってみた印象としては、C#を使うプロジェクトで、それなりの人数が参加する場合はStyleCopを最初から適用する。さらに、いろんなところから参照されるアセンブリ（共通ロジックなど）はFxCopも適用する。というのがよろしいんではないかなー。と思っております。

ちなみに、ある程度開発が進んだ途中から、これらの静的解析を適用するのは、手間が大きすぎるので、可能な限り開発の着手前に決めておくべきでしょう。

なお、表には記載していませんが、StyleCopはオープンソース(Microsoft Public License：Ms-PL)に対して、FxCopはWindows SDKの一部であり、ソースは公開されていないという違いもあります。

それぞれ、インストール方法や使い方などについてはググってみてください。結構たくさん参考になるサイトが出てきます。

FxCopとStyleCop。もう少し続けます。