StyleCop – MicrosoftのC#用スタイル強制ツール

作者 Jonathan Allen , 翻訳者 編集部 投稿日 2008年6月9日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

シンタックス ,

.NET ,

プログラミング

タグ

Coding Standards ,

C#

スタイル強制は長年にわたり激しく議論されてきたテーマである。チームはどのようなスタイルを標準化すべきかの議論だけでなく、標準のスタイルは存在すべきかどうかの議論もある。事態をさらに悪化させるような動きとして、Microsoftが社内で使用しているスタイル強制ツール、StyleCopを公開した。

Microsoft Source Analysis for C#としても(source)知られるStyleCopは、FxCopと同等のソースコード分析ツールである。FxCopと同様にStyleCopはもともとMicrosoftの社内で使用されていたツールであり、それが他の人にも役立つとMicrosoftが見なすまでに成長した。しかしFxCopと違って、それほど高度に設定可能なものではない。

Source Analysisの究極の目標は、コードを見るチームメンバーやその他の人が高い可読性を見いだせるような、優雅で一貫したコードを生成できるようにすることです。これを達成するために、Source Analysisは、そのルールを高度に設定可能にすることを許しません。Source Analysisは、コードのスタイル、レイアウト、および可読性のルールに対しオールマイティなアプローチを取ります。最初は、すべてのルールに同意できず、一部のルールを煩わしいとさえ感じる場合があるということは大いにあり得ます! しかし、Microsoft社内でこのツールを使用しているチームの大半が、短い調整期間後、Source Analysisによって強制されるルールを有り難く思うようになり、このスタイルで記述されなかったコードが読みづらいとさえ感じるようになったことに気付きました。

Jason Allor氏は、このツールで強制される約200のルールがVisual Studioにあるデフォルト設定と互換性があるということを主張している。残念ながら、彼は、Visual Studioには6つのまったく異なるデフォルト設定の集合があり、その多くがこのツールと直接に矛盾していることをきちんと述べなかった。

ツールがカバーしている範囲は次のとおりである。

• ファイルの許容コンテンツ
• デバッグテキスト
• 要素ヘッダーとファイルヘッダー内のドキュメントの書式設定
• 要素、ステートメント、表現方法、およびクエリ句のレイアウト
• 行間
• 要素、フィールド、および変数の命名
• 波括弧、丸括弧、角括弧などの配置
• メソッド宣言またはメソッド呼び出し内のメソッドパラメータの配置
• キーワードと演算子記号付近のスペース*
• クラス内の要素の標準の順序
• アクセス修飾子の使用
• 組み込みの型の使用

.これらのルールを空のコンソールアプリケーションに対して実行すると、9つのエラーが返される。「Keep Tabs」をオンにしている場合は16のエラーが返される。一部のルールは、「using」ディレクティブをファイルの先頭ではなく名前空間内にする必要があるなど、かなり厄介である。

すでに、ツールの修正サポートの不十分さについての不平不満がある。Dustin Norman氏は次のように書いている。

このツールをかなり小さいアセンブリで実行した者としては、561の違反をこのツールがコードのセマンティクスに影響を与えることなく自動で修正できたとき、それを手動で修正することを考えるとちょっと気が遠くなります。

タブvsスペースに関する長年の議論が再び高まっている。特定のルールを無効にできないことについても議論されている。Nick Berardi氏は次のように書いている。

冗談でしょ。「タブは許可されません。代わりにスペースを使用してください。」とは、恐ろしい考えです。なぜなら、ある変数が3つのスペースを使用して別の変数が4つのスペースを使用する場合、レイアウトのブロックを混乱させるからです。とにかく、こうしたタブのルールのように、一部の無意味なルールは無効にすることです。

こうした一部のルールを無効にできたら良いでしょうに。それが最善の選択であるとあなたが言ったのを私は知っています。しかし、私はスペースよりもタブという考えにまったく同意できません。その論理的な理由はまったくありません。Viが最初に発売されて以来、開発者の間で繰り広げられた聖戦は除きます。私はぜひ自身のソースコードでこれを実行したいと思いますが、タブを含むすべての行について警告されるため、失敗に終わるでしょう。

一方で、Daniel Stolt氏はVBについて尋ねている。

これは.NET開発者にとって利用可能なツールセットへの大変喜ばしい追加です。しかしなぜ、C#専用なのでしょうか? コードの書式設定ルールの強制は、VB開発者にも非常に必要とされています!

確かに、VBコードエディタには、キーワードや記号付近のインデントやスペースに関しては自動書式設定に対する基本的なサポートがあるが、StyleCopがサポートするものには近づきすらしません。

ところで、私はタブvsスペースについて「nberardi」 [Nick Berardi氏] に完全に同意します。タブに関する問題は何ですか? 所定の地点に達するために矢印キーを4、5倍多く押さなければならないことは利点ですか? ソースファイルに4、5倍多くの空白文字を格納しなければならないことは利点ですか?

少なくとも自動修正をサポートすることに何らかの関心があるようだが、タイムラインは与えられなかった。

原文はこちらです：http://www.infoq.com/news/2008/05/StyleCop

• 次へ >