StyleCopの可能性を広げる

スタイルマッチング用の静的C＃コードアナライザーであるStyleCopは、2008年初頭に公式に公開されました。 IT標準では、これはかなり前のことですが、何らかの理由で、この便利なツールはまだ広く普及していません（少なくともそれに値するもの）。



以下では、理由を分析するとともに、StyleCopの新しいプラグインについて説明します。

---

StyleCopがあまり人気がないのはなぜですか？

コーディングスタイルをまったく気にかけない開発者（以下、C＃言語のみに焦点を当てます）に加えて、デフォルト設定でのエラーが多すぎると、多くの人が怖がってしまいます。 私の意見では、これは奇妙です。コーディングスタイルが心配な場合は、すべての設定をチェックして、選択したスタイルに従うのに適した設定を自分で決定するのが自然です。



しかし、ここで疑問が生じます-コーディングスタイルによって一般に理解されることは何ですか？ これは、C＃で書くすべての人にとって何らかの統一されたスタイルですか？ または、各チームが自由に選択できますか？



私には、「均一な」ルールの存在というまさにアイデアが理想的であるように思われます。 一般に、時間の経過とともにますます多くの開発者が順守し始めている傾向があります。 しかし、言語は開発されており、新しい構造が追加され（それらを使用する方法が増えていることを意味します）、議論と紛争の新しい波が始まります。



それにも関わらず、StyleCopの作成者であり、イデオロギーの主な発想者であるJason Allorは、スタイルのルールは誰にとっても同じであるという立場を固守しています。 その結果、これらのルールは非常に「デフォルト設定」を構成し、StyleCopを使用したい人をしばしば停止させます。



特定のルールに関する紛争を引き起こしたくありません-最終的に、StyleCopによって提案されたスタイルは、Microsoftの一部のチームによって使用されます（つまり、特定の「信頼係数」を持っています）。 しかし、私の個人的な経験から、「ローカルスタイル」の原則が最もよく機能することがわかります。つまり、 彼のスタイルは、チーム、部門、または組織全体で採用され、その後厳密に観察されます。

ここで、口頭協定でのみ契約が締結された場合、契約を締結していないとみなすことができます。 強制検証（たとえば、ビルドサーバーでのアセンブリの段階の1つとして）は、コンプライアンスの唯一の保証です。 ここでは、StyleCopなどのツールが栄光に満ちています。

どうすれば状況を修正できますか？

幸いなことに、StyleCopにはプラグインシステムがかなり開発されており、その機能を大幅に拡張できます（元のルールのセット自体も技術的に別のプラグインとしてフレーム化されています）。 しかし、パブリックドメインにはStyleCopのプラグインはそれほど多くありません。 そして、見つけることができるそれらのほとんどは、いくつかの散在したルールであり、見捨てられています。



StyleCopは、特定のスタイルを守るための道具として位置付けられていなければ、より便利になりますが、チームが必要とするスタイルのコンプライアンスを制御できる一種の「デザイナー」になります。

StyleCop +

約1年前、そのような考えを持って、 StyleCopの別のプラグインであるStyleCop +を書き始めました。 彼の主なアイデアは変わりませんでした-特定のルールを課すことなく、可能性のある幅広いチェックを提供して独自のスタイルをカスタマイズします。



プラグインは余暇にゆっくりと作成され、新しい機会で徐々に大きくなりました。 最終的に、ベストプラクティスを共有することにし、CodePlexでの公開を開始しました。 肯定的なレビューは、作業が無駄ではないことを示しました。



以下に、StyleCop +の主な機能について簡単に説明します。 既にStyleCopを使用している場合、それらはあなたにとって興味深いように思えるかもしれませんが、そうでない場合、それはあなたにとって十分ではなかったかもしれません。

高度な命名規則

これらのルールの出現の歴史は非常に平凡です-私たちのチームはクラスフィールドにm_fieldスタイルを採用しました （プライベートフィールドの名前がさまざまなプレフィックス、特にm_で始まる場合）。 StyleCopはthis.field-スタイルのみをサポートします（プライベートフィールドにプレフィックスがありませんが、クラスのフィールドまたはメソッドへのアクセスには、メソッド引数などとフィールドを区別するために必須のthisが必要です）。 さらに、StyleCopには、一般的に名前にアンダースコアを使用することを禁止するルールも含まれています。



繰り返しますが、どちらのスタイルのほうが良いとは言いません。 しかし現実には、さまざまなスタイルが既に存在します（.NET BCLでも、さまざまなコマンドによってさまざまなタイミングで、さまざまな命名スタイルで記述されたクラスのグループを観察できます）。 もしそうなら、スタイルに従うためのツールはこの多様性をすべて考慮に入れなければなりません。



したがって、StyleCop +には、ほとんどすべてのネーミングオブジェクトのシステムを構成できるルールがあります。 機能的には、基本的な命名規則 （ SA13xx ）を完全にカバーしているため、後者は単純にオフにできます。







これらのルールを構成する方法は、ReSharperの同様の設定と多くの点で似ています-独自の命名パターンを設定できる広範囲のエンティティを使用できます。







たとえば、次のルールでは、名前は接頭辞m_で始まり、その後にcamelStyle （ m_rulesMap ）の名前が続くか、 PascalStyle （ RulesMap ）で完全に記述される必要があります。







図からわかるように、命名パターンでは、最も一般的な大文字のスタイルを説明する多数のマクロを使用できます。



エンティティ自体も非常に多く、それらの一部は特別に個別に強調表示されています。 たとえば、標準のWinFormsイベントハンドラー（ buttonStart_Clickなど）の名前を変更したくない場合があります。つまり、通常のメソッドとは異なり 、独自のルールが必要になる場合があります。 または、単体テストであるメソッドを特別に呼び出す場合があります（たとえば、 Setting_Null_Throws_Exception ）。 また、アクセス修飾子に応じて、クラス名またはフィールド名に異なるルールを設定する必要があることは明らかです。



名前の大文字と小文字がチェックされるため、独自の略語リストを設定せずに済ませることはできません（ここでは、大文字と小文字の組み合わせを別の単語として許可する必要があります）。 一部の派生クラスの名前が必ず基本クラスの名前で終わることを保証できるオプションも最近登場しました（たとえば、これはAttribute 、 Exception 、 Streamなどに共通ですが、誰かが例外を追加したい場合があります）。

その他のカスタムルール

他のプラグインと同様に、StyleCop +にはスタイルをチェックするためのさまざまな追加ルールが含まれています。 それらの多くはまだありませんが、存在するものは非常に柔軟に構成されています（多くの興味深いアイデアを提案したアクティブユーザーのおかげです）。



これらのルール用に個別のインターフェイスが作成され、設定のよりわかりやすい編集が可能になりました（ルールタブの従来のインターフェイスとは異なり、ここでの設定はブール値のフラグに限定されず、ルール自体に適用されます）。

拡張オリジナルルール

これは実験的な機能であり、StyleCop +には、元のStyleCopルールを「寄生」するルールが含まれています。 たとえば、有用なルールSA1509：OpeningCurlyBracketsMustNotBePrecededByBlankLineは、コードの「組み込み」ブロックも禁止しています。

// some statements ... { int a; // declaration of local variables required to set value of f1 ... this.f1 = ...; } { int a; // declaration of local variables required to set value of f2 ... this.f2 = ...; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その「寄生虫ルール」 -SP1509-には、このスペルを許可する設定が含まれています。 重要な点は、このルールには元のチェックを複製するネイティブコードが含まれていないことです。 代わりに、「寄生ルール」はStyleCopから元のコードを起動しますが、結果に独自の制限を課します（上記の例では、「組み込み」コードブロックが原因でエラーが発生しません）。

結論の代わりに

StyleCopをまだ使用していない場合は、ぜひ試してみてください。これはあなたの必須ツールになるはずです。

機能が不足している場合は、拡張機能を作成するか、既存の拡張機能を探してください！



StyleCop +に関しては、進化を続けています。 CodePlexのダウンロード、使用、質問。 そして、少なくとも1人の開発者にStyleCopの使用を開始するように促すのが彼である場合、このプロジェクトは100％の使命を果たしたと想定できます！



頑張って

____________________

• http: //stylecop.codeplex.com-CodePlexのStyleCop
• http: //stylecopplus.codeplex.com-CodePlexのStyleCop +
• http://blogs.msdn.com/b/sourceanalysis-Microsoft StyleCopブログ
• http://devjitsu.com/blog-Jason Allorブログ