読者です 読者をやめる 読者になる 読者になる

give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

C#のコード品質を上げるフリーツール8本

C#

はじめに

読みにくいコードや複雑なコードをメンテナンスするのってイヤですよね。
コードの品質を上げる方法の一つにコードレビューがありますが、すべてのソースコードを人力でチェックしていくのは大変ですし、レビュアーのスキルや好みにも大きく依存してしまいます。


そういう場合はツールを使って自動化するのが有効です。
ツールを使えばあっという間に完了しますし、実施者のスキルや好みに左右されることもありません。
しかし、あまりお金がかかるツールだと、ちょっと気軽に導入しにくいです。


そこで今回はC#のコード品質向上に有効なフリーツールを紹介します。
実際のプロジェクトで使用したことがあるものばかりなので、どれも「使えるツール」だと思いますよ。


ところで、ツールを紹介する前にTipsと注意点を簡単に挙げておきましょう。

ツールを利用する際のTips
  • 自分の書いたコードのみを対象とし、ツールが作成したコードは対象外にしましょう。Projectやネームスペースを別にして、自分の書いたコードとツールが自動生成したコードを簡単に識別できるようにしておくことが重要です。
  • ただし、ヘルプファイル(APIドキュメント)作成時は自動生成されたコードも出力対象にしてよいと思います。(そこだけ不完全なヘルプになるかもしれませんが)
  • UIはテストしにくいので、自動化テストやコードカバレッジの対象外とすることを検討すると良いかもしれません。もちろん、主要なロジックはUIの外に切り出す設計にしておくことが重要です。
  • 自分の組織、または開発プロジェクトでツールのバージョンやオプションを統一しておきましょう。実行したメンバーやPCによって結果が異なると、ツールの存在意義が低下してしまいます。たいていのツールには設定ファイルがあるので、それをバージョン管理ツールなどで共有すると良いと思います。
  • ツールの有効性が確認できたら、さらに高機能な有料ツールの導入を検討するのもいいでしょう。
これから紹介するツールの注意点
  • 確認した環境はVisualStudio 2005/C# 2.0です。2008/3.5や2010/4.0での動作確認はできていません。*1
  • ツールのトップページは時々変わるので、時間が経つとリンクが切れている場合があります。リンクが切れていなくても、最新版のトップページが全く違うURLになっていたりすることもあるので、Googleなどで最新情報を検索しなおすことをお勧めします。
  • ツールの中には開発があまり活発ではないものもあります。開発環境がアップデートされてそのツールが使えなくなるリスクもある程度考慮しておく必要があります。
  • 今まで無料だったツールが突然有料になったりすることがあります。まあ、ボランティアでツールを開発している方はいないと思うので、そのときは諦めてください。
  • 使い方についてはここでは詳しく書きません。公式サイトの情報やネット上の記事などを参考にしてください。特にWebSiteは他のProjectと大きく構成が違うのでツールが適用しにくいことがあります。


それではツールの紹介に移りましょう。

C#のコード品質を上げるフリーツール

StyleCop

Project内のソースコードがコーディングルールに従っているかチェックしてくれます。
時々、VisualStudioがデフォルトで作成するコードからすでにルール違反が含まれていたり、日本語環境ではどうしようもないルール違反を報告されたりするので、自分のProjectにあわせてルールのオプションを変更してください。

公式サイト
StyleCop - Home
FxCop

ソースコードではなく、アセンブリ(dll/exe)の品質チェックをしてくれます。
クラス名やメソッド名にスペルミスがあったりすると教えてくれます。
ただし、そのアセンブリを他のProjectで使うのでなければチェックが厳しすぎるところもあるので、自分のProjectにあわせてルールのオプションを変更してください。

公式サイト
Download: FxCop 10.0 - Microsoft Download Center - Download Details
SourceMonitor

サイクロマチック複雑度やネストの深さなどをチェックしてくれます。
コードのシンプルさ、複雑さを定量化することができます。

公式サイト
SourceMonitor V3.2
Duplo

コードの重複を発見してくれます。
ただし、実行するには自分でC++のコードをコンパイルする必要があります。
異なるファイル間の重複は発見してくれますが、同一ファイル内の重複は発見してくれないのがちょっと難点です。
ファイルの一覧をテキストファイルとして作成し、それをDuploに食わせるので一発では解析できません。
おいらは一発で解析できるように、自動化バッチ(厳密にはhtaで作ったGUI)を作成しました。

公式サイト
Duplo | Free Development software downloads at SourceForge.net
NUnit

言わずと知れた自動化テストツールです。
VisualStudioから起動&デバッグ実行ができるように、ProjectのBuildプロパティを変更しておきましょう。

公式サイト
NUnit - Home
PartCover

NUnitと組み合わせてコードカバレッジを解析します。*2
実行時のプロパティ設定にちょっとクセがあるので、最初は少し苦労するかもしれません。

公式サイト
sawilde/partcover.net4 · GitHub
GhostDoc

コンテキストメニューやキーボードショートカットを使って簡単にXMLドキュメント・コメントを作成できます。
クラスやメソッドに適切な英語名が付いていると、それっぽい英文コメントも自動生成されます。
まあ、日本語でコメントを書きたい場合は無用な機能になってしまいますが・・・。

公式サイト
SubMain / GhostDoc - Simplify your XML Comments!
Sandcastle

XMLドキュメント・コメントからヘルプファイル(APIドキュメント)を作成してくれます。
オプションが豊富にあります。逆に言うと、オプションが多すぎて何をどう設定すればいいか迷うかもしれません・・・。
昔はNDocという似たようなツールがありましたが、開発が止まっているようなので、Sandcastleを使った方が良いと思います。

公式サイト
Sandcastle Help File Builder

ツールを使えばすべて完璧?

いえいえ、そんなわけはありません。
これらのツールを使えば、可読性や信頼性といったコードの品質が向上するのは間違いありません。
しかしそうはいっても、これらのツールがコードの品質を完璧にしてくれるわけでもありません。
ツールを使ってもツールではチェックできない部分も色々とあるので、人力のコードレビューもある程度必要になると思います。
もちろん、それが機械的に判断できる内容なのであれば、他のツールを探したり、自分たちでチェックツールを作ったりすればさらに完璧ですね。

手段と目的を取り違える人もいる

たとえば実際の開発プロジェクトでメトリクスの目標値を決めたとします。
コードカバレッジは100%とか、StyleCopの検証をすべてパスさせるとか。
しかし、開発者がその気になればツールを欺くこともできます。
カバレッジは100%でもNUnit側で大した内容を検証していなったり、適当なXMLドキュメント・コメントしか入れてなかったりという具合です。
残念ですが、開発に参加する人の中にはそういう悪知恵を働かす人間が紛れ込むこともあるので、ツールが値だけを鵜呑みにせず、時々自分の目で確かめることもしましょう。

あわせて読みたい

SourceMonitorの活用事例を紹介しています。
数値で測るコード品質 - give IT a try


テストを自動化する際の注意点をまとめてみました。
自動化テストで気をつけること - give IT a try


ツールを使ってもレガシープログラマの判断項目をスルーしてしまう恐れはあるので要注意!
レガシープログラマかどうかを判断する10項目 - give IT a try


ツールの測定値を組織の指標とするときは、こうした弊害にも注意しましょう。
おかしなおかしな目標管理 - give IT a try

参考文献

ここで挙げたツールはこの本にインスパイアされて探し出したものです。
最終的にはNAntCruiseControlなんかを使ってCI(継続的インテグレーション)までできれば完璧なんですが。


.NETライブラリの開発者が自らライブラリの設計指針を説明してくれます。
.NETの命名規則や設計ポリシーを学ぶのに打ってつけです。
ただし、訳がかなり読みにくいのが難点(> <)


C#の標準的なコーディングルールがうまくまとめられています。
コーディングルール検証はツールに任せっきりにするのではなく、こうした本を読んで、どういったルールがあるのか、なぜそのルールを適用するのか、といったことも理解しておきましょう。

*1:古い環境でごめんなさい m(_ _)m

*2:厳密に言うとNUnitである必要はありません