InfoQ

News

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

作者 Jonathan Allen , 翻訳者 編集部 投稿日 2008年6月9日 午前12時59分

コミュニティ
.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

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
slashdot+
Hatena

特集コンテンツ一覧

Agile Japan 2009

2009年4月22日、東京千代田区にある放送会館で「アジャイルジャパン2009」が開催されました。本イベントは「ソフトウェア開発の次世代リーダーをつくる」ことを合い言葉に、200人以上の参加者を集めてスタートしました。

Flex 4の新機能トップ10

今週(2009年6月1日)AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumboというコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。

Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。

JavaプログラマがFlexとBlazeDSを学んだ方がいい13の理由

この記事ではJavaプログラマがなぜFlexとBlazeDSを学ぶべきなのかについて13の理由を述べています。なぜ高度にインタラクティブなWeb サイトからJavaで開発されたバックエンドをもつエンタープライズ・アプリケーションまでを含む、リッチ・インターネット・アプリケーション(RIA)の開発にFlexとBlazeDSの組み合わせが最適な選択肢となるのかについて述べています。

仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?

Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。

Perf4Jを使ったパフォーマンス解析とモニタリング

この記事ではAlex Devine氏が、Java開発者がPerf4Jをどのように利用できるかと、タイミングステートメントにコードを追加し、ロギング、結果の解析とモニタリングを行うオープンソースツールセットの説明をします。

複雑な外部DSLを開発する

本稿では、Vaughn Vernon氏が内部DSLと外部DSLの違いを説明し、複雑な外部DSLを開発する際のステップを示します。

J2EEアプリケーションにおけるAOPを使ったフェッチ戦略の実装

この記事では低レベルのサービス・レイヤやリポジトリ・レイヤを肥大化させることなく、フェッチング・ストラテジによってモジュール化された方法でバックエンドにあるシステムからデータを取得する処理を最適化する方法について説明します。