22

私は、StyleCop で広範なルールセットを使用するチームで働いていますが、そのようなツールが役に立たなくなり、煩わしくなる一般的な点についてどう考えているのだろうかと思っています。また、GhostDoc を使用しているため、コードは XML コメントで埋め尽くされており、コードが読みにくく、レビューが困難になっています。私は XML コメントに問題はなく、場所によっては非常に便利だと思いますが、すべてのフィールドとプロパティで本当に必要なのでしょうか?

「各プロジェクトは、ビルド時に警告が 0 でなければならない」という立派な目標がありますが、この目標は妥当な StyleCop ルールセットに反するものでなければなりません。

これについてどう思いますか？

EDIT 私は今、実際にstylecop AT ALLのようなツールの議論は何なのか疑問に思っています? それを捨てて、賢明なコーディング標準と優れたコードレビューに残りを任せてみませんか? 特に有能なチームでは？確かに、すべての警告が関連するため、0 の警告を取得するタスクは実際に価値を追加します。

GhostDoc の唯一の利点は、XML コメントをゼロから作成するのに必要な数秒を節約できることだと思います。生成されたコメントを編集せずに受け入れる必要はないと思います-これはおそらく非生産的です。

これは、Stylecop ルール (SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText) が GhostDoc によって生成された xml コメントによって満たされている組み合わせです - 一日の終わりに値を追加しますか?

    /// <summary>
    /// Initializes a new instance of the <see cref="SomeCustomType"/> class.
    /// </summary>
    /// <param name="someParameter">The someParameter.</param>
    public SomeCustomType(string someParameter)
    {
    }
4

6 に答える 6

25

これは質問というより暴言だと思いますが、次の点には同意します。

  • スタイルのルールを過度に適用することは悪いことです。

ソース コードの書式設定に関するガイドラインがあることは明らかですが、過度に規範的で破ることのできないルールは、不快なコーナー ケースにつながります。すべてのケースでルールに厳密に従うと、読みにくいほど乱雑なコードや過剰にラップされたコードが生成される可能性があります。

コーディングはさまざまな文章であり、オーウェルのボーナス ルール (「あからさまに野蛮なことを言うよりも早く、これらのルールを破る」) をコーディング スタイル ガイドにも適用する必要があります。

スタイルガイドを設定して理解できる有能なプログラマーのチームで、自動化されたスタイルの適用が良い考えであることに私は懐疑的です。自動化された lint は偶発的な間違いを見つけるのに役立ちますが、コードの書式設定に関する非常に規範的な法則を適用すると、Orwell の規則を考慮することができなくなります。強力なルールセットを使用すると、保守性を装って、保守性の低いコードを書かざるを得なくなる可能性があります。

チームに能力の低いコーダーがいて、スタイルを強制されない限り出力がごちゃごちゃしている場合は、強制することをお勧めします。（しかし、おそらくもっと大きな問題を抱えているでしょう！）

  • 自動コメントは非常に悪いことです

私は GhostDoc を見たことがありませんでしたが、実際には少しショックを受けました。

独自のフロントページのまさに例：

/// <summary>
///     Determines the size of the page buffer.
/// </summary>
/// <param name="initialPageBufferSize">
///     Initial size of the page buffer.
/// </param>
/// <returns></returns>
public int determineBufferSize(int initialPageBufferSize) {

は、悪いコメントのほぼ標準的な例であり、それが文書化するコードへの洞察をまったく追加しません。これは、コメントドキュメントがないよりも絶対に悪いです。

Javadoc に従ったすべての in-source-doc スキーマは、コードを読む読者とはまったく異なる対象者であるエンドユーザーを対象とした資料でソースコードを乱雑にするため、少し疑わしい場合があります。しかし、これは絶対的な落とし穴です。誰がこれを良いアイデアだと思ったのか、私には想像できません。

于 2010-07-08T12:24:27.127 に答える
13

StyleCop はツールです。箱から出してすぐに完璧であることは想定されておらず、すべての人のニーズを満たすことも想定されていません。

個人的には、「はい、重要です」と言います。なぜなら、開発チームを運営している場合、StyleCop はコーディング ガイドラインが遵守されていることを確認するのに役立つからです。それがまさにその目的です: 自動化された、測定可能な、一貫した方法でコーディング標準を評価することです。ビルド プロセスでそれを実行したくない場合は、その通りです。それは時間の無駄です。

あなたは自分で言います: ゼロ警告の目標は、「合理的な StyleCop ルールセットに反する必要があります」。ニーズに合わない構成でツールを実行しても意味がありません。ルールがあなたにとって「煩わしい」場合は、それをオフにしますが、他の誰かにとっては非常に重要な場合があります。

あなたの「価値を追加しますか」という質問については、はい。人々は一貫性の価値を過小評価しています。すべてのコンストラクターが同じスタイルのコメントを持っている場合、プロジェクト内のプロパティのすべての Intellisense が同じ構造を持っている場合、対処する精神的なハードルが (どんなに小さくても) 1 つ少なくなります。また、それを自動化するツールを使用すると、ほとんど手間がかかりません。何について不平を言うのですか？

于 2010-07-09T07:51:05.250 に答える
4

ルールをコーディングするのに、メンテナンスの削減によって得られるよりも多くの時間がかかる場合。

ご存知のように、バグを修正するには、それを書くよりもはるかに時間がかかります。そのため、しきい値に達する前に、コードをより堅牢で保守しやすいものにするために、かなり多くの余分な作業を行うことができます。

于 2010-07-08T12:32:04.220 に答える
3

コードが適切に記述され、読み取り可能で保守可能であることは非常に重要ですが、コードには Visual Studio と Resharper の自動コード フォーマット ヘルパーを使用し、AtomineerUtils を使用して XML ドキュメント コメントを厳密に定義されたきちんとしたフォーマットに保ちます。

その結果、メインの StyleCop ルールは無関係です。コードは常に「デフォルトで」重要なルールに従っているからです。下位の StyleCop ルールは、日常的に使用するには厳しすぎる傾向があります。(これらのルールのほとんどは、コードの品質や可読性を向上させるとしてもごくわずかなものにすぎないため、それらを順守するコストは容認できないと考えています。プログラマーには、コードがチーム内の他のメンバーが簡単に読めるようにするため、コーディング スタイルの小さな違いは気にしません)。そのため、StyleCop を評価した後、実際の利点を見つけることができませんでした。

対照的に、FXCop は非常に有用であると考えています。なぜなら、それが強調する問題は単なる読みやすさの問題だけではなく、重大なバグやパフォーマンスの問題を時折拾い上げるからです。

于 2010-07-09T07:40:24.517 に答える
1

あなたの質問で気になった点がいくつかありますので、以前の回答にいくつかの考えを追加したいと思います。

私は XML コメントに問題はなく、場所によっては非常に便利だと思いますが、すべてのフィールドとプロパティで本当に必要なのでしょうか?

一部のフィールドとプロパティは、誰にとっても明らかであるため、説明は必要ありません。たとえば、クラスに、およびCoordinateのプロパティがある場合、コメントで説明することは何もありません。XYZ

しかし、StyleCop のようなツールに関して言えば、ツールは、ソース コードを初めて発見したときに、明白なプロパティと理解するのが難しい可能性のあるプロパティを区別することはできません。いいえ、コメントはどこでも必要というわけではありませんが、すべてのフィールドとプロパティにコメントを適用するか、ルールを無効にして開発者に決定させます。

これは、Stylecop ルール (SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText) が GhostDoc によって生成された xml コメントによって満たされている組み合わせです - 一日の終わりに値を追加しますか?

何とかして。一部のツールでは、他のメソッドと同じようにコンストラクターが表示されますが、この 2 つを視覚的に区別することはできません (クラスの名前を覚えていない限り)。一方、XML コメントは非常に明確であるため、これがコンストラクターであることが非常に簡単に理解できます。

ところで、ここに他に何を書きますか？

  • 他の何か？コンストラクターの標準がないと、コードを読むのが難しくなり、両方が同じように表示されるビューでメソッドがコンストラクターであることを理解するのが難しくなります。

  • ノーコメント？このようなコメントはクラスの名前から簡単に生成できるため、解決策になる可能性があります。しかし、それは物事をより複雑にします (なぜ、他のメソッドではなく、コンストラクターに対してコメントを自動生成するのでしょうか?)。また、このコンストラクターの説明を提供しない場合、誰かが何であるかをどうやって知ることができsomeParameterますか?

最後に、あなたの質問に答えるために、すべての StyleCop ルールがすべての場合に常に役立つとは誰も言えません。ただし、ここでのナンセンスは、StyleCop 自体ではなく、「ビルド時に各プロジェクトの警告が 0 でなければならない」という目標であることを忘れないでください。あなたが経験豊富な開発者で、きれいなコードを書くのであれば、StyleCop ルールをオフにしない理由はありません。少なくとも、それらの意味、ルールがここにある理由、ルールに従わない場合の結果をよく理解していればです。

私たちの会社では、すべてのプロジェクトに StyleCop を使用するというポリシーがあり、小さなプロジェクトに何百もの警告がある場合は、問題があります。同時に、クラス全体でいくつかの StyleCop ルールを無効にする状況がよくありました。それらを強制するのに時間がかかり、誰にも何ももたらさないからです。一方、同僚がクラス、メソッド、およびプロパティの名前をフランス語で記述できるようにするためだけに FxCop/StyleCop を無効にしたとき、私はまったく感謝しませんでした (私はフランスの会社にいて、英語を話す開発者とも仕事をしています)。 ）、したがって、一部の人にとっては、両方のツールを毎回有効にする必要があり、それらを無効にすることはできません.

于 2011-04-09T20:44:20.687 に答える