8

.NET ソース内のコード ドキュメントの量が多すぎますか?

いくつかの背景: SO に投稿した他の質問のいくつかで話した大きなコードベースを継承しました。このコードベースの「機能」の 1 つは、God クラスです。これは、数十の静的メソッドを含む 3000 行を超えるコードを持つ単一の静的クラスです。Utilities.CalculateFYBasedOnMonth()からまでのすべてUtilities.GetSharePointUserInfo()ですUtilities.IsUserIE6()。適切なライブラリ セットにリファクタリングするだけで、書き換える必要のない優れたコードです。私はそれを計画しています。

これらのメソッドは新しいビジネス レイヤーに移行しており、このプロジェクトでの私の役割は、他の開発者がシステムを保守できるように準備することなので、しっかりしたコード ドキュメントについて考えています。これらのメソッドにはすべて適切なインライン コメントがありますが、XML コメント形式の適切な (またはまったく) コード doco がすべて含まれているわけではありません。GhostDoc と Sandcastle (または Document X) の組み合わせを使用して、非常に優れた HTML ドキュメントを作成し、それを SharePoint に投稿できます。これにより、開発者は、コード自体をナビゲートしなくても、コードが何をするかをより理解できるようになります。

コード内のドキュメントの量が増えると、コードをナビゲートするのが難しくなります。//commentXML コメントを使用すると、たとえば、各メソッドを単純にするよりも、コードの保守が難しくなるのではないかと考え始めています。

これらの例は、ドキュメント X サンプルからのものです。

        /// <summary>
        /// Adds a new %Customer:CustomersLibrary.Customer% to the collection.
        /// </summary>
        /// <returns>A new Customer instance that represents the new customer.</returns>
        /// <example>
        ///     The following example demonstrates adding a new customer to the customers
        ///     collection. 
        ///     <code lang="CS" title="Example">
        /// CustomersLibrary.Customer newCustomer = myCustomers.Add(CustomersLibrary.Title.Mr, "John", "J", "Smith");
        ///     </code>
        ///     <code lang="VB" title="Example">
        /// Dim newCustomer As CustomersLibrary.Customer = myCustomers.Add(CustomersLibrary.Title.Mr, "John", "J", "Smith")
        ///     </code>
        /// </example>
        /// <seealso cref="Remove">Remove Method</seealso>
        /// <param name="Title">The customers title.</param>
        /// <param name="FirstName">The customers first name.</param>
        /// <param name="MiddleInitial">The customers middle initial.</param>
        /// <param name="LastName">The customers last name.</param>
        public Customer Add(Title Title, string FirstName, string MiddleInitial, string LastName)
        {
            // create new customer instance
            Customer newCust = new Customer(Title, FirstName, MiddleInitial, LastName);

            // add to internal collection
            mItems.Add(newCust);

            // return ref to new customer instance
            return newCust;
        }

と:

    /// <summary>
    /// Returns the number of %Customer:CustomersLibrary.Customer% instances in the collection.
    /// </summary>
    /// <value>
    /// An Int value that specifies the number of Customer instances within the
    /// collection.
    /// </value>
    public int Count
    {
        get 
        {
            return mItems.Count;
        }
    }

だから私はあなたから疑問に思っていました: NDoc (RIP) や Sandcastle のようなものを使用することを目標に、すべてのコードを XML コメントで文書化していますか? そうでない場合、ドキュメントを取得するものと取得しないものをどのように決定しますか? API のようなものには明らかに doco がありますが、別のチームに引き渡して維持するコードベースについてはどうでしょうか?

私は何をすべきだと思いますか?

4

14 に答える 14

8

コードを肥大化する必要がないことは誰も言及していません。XML ドキュメントは別のファイルにある可能性があります。

/// <include file="Documentation/XML/YourClass.xml" path="//documentation/members[@name='YourClass']/*"/>

Add メソッドには、その上に余分な XML/コメントを含めることはできません。または、要約だけを好む場合は (別のファイルにマージされるため)。

これは、Javadoc や、PHP/Javascript で見られる派生形式であるゴミ形式よりもはるかに強力です (ただし、Javadoc は XML 構文への道を開きました)。さらに、利用可能なツールははるかに優れており、ヘルプ ドキュメントのデフォルトの外観はより読みやすく、カスタマイズしやすいものになっています (ドックレットを作成し、そのプロセスを Sandcastle/DocProject/NDoc と比較すると、そう言えます)。

于 2009-02-18T10:35:38.123 に答える
5

ここでの問題のかなりの部分は、MS が私たちに押しつけた冗長で粗雑な XML ドキュメント構文にあると思います (JavaDoc もそれほど優れていませんでした)。それをどのようにフォーマットするかという問題は、どの程度が適切かということとは、大部分は無関係です。

コメントに XML 形式を使用するかどうかは任意です。DOxygen またはさまざまな形式を認識するその他のツールを使用できます。または、独自のドキュメント エクストラクタを作成します。合理的な作業を行うのは、思ったほど難しくなく、良い学習体験です。

どれだけ難しいかという問題。いくつかのコードを維持するために掘り下げている場合、自己文書化コードのアイデアは問題ないと思います。あなたが単なるクライアントである場合、コードを読んで特定の機能がどのように機能するかを理解する必要はありません。もちろん、多くの情報がデータ型と名前に暗黙的に含まれていますが、そうでない情報もたくさんあります。たとえば、オブジェクトへの参照を渡すと、何が期待されているかがわかりますが、null 参照がどのように処理されるかはわかりません。または、OP のコードでは、引数の先頭または末尾の空白がどのように処理されるか。この種の情報は、通常認識されているよりもはるかに多く文書化する必要があると思います。

私にとっては、関数の目的、および関数の事前条件と事後条件、その引数、およびプログラミング言語の構文では表現できない戻り値を記述する自然言語ドキュメントが必要です。

于 2008-11-13T21:22:42.497 に答える
3

ここで、新しいライブラリを維持する側と新しいライブラリを使用する側との間に重大な違いがあります。

新しいアプリケーションを作成していて、これらの標準ライブラリを使用する場合は、ライブラリの安定したバイナリを取得してアプリケーションにインポートする必要があります。ソース コードをある場所からコピーして問題を引き起こす可能性はありません。変更されます。その場合、メソッドの名前と入出力パラメーター以外の「自己文書化」機能にはアクセスできません。また、何らかの IDE を使用している場合は、これらの機能でさえ公開されません。オートコンプリート機能がオンになっていないもの。

したがって、上記のコード例では、問題なく見えると思います。コード自体はあまり冗長ではなく、名前は自己文書化されています。反対に、必要な要約/パラメーター データはすべてそこにあるため、ライブラリを使用するユーザーがすべての重要な情報をすぐに利用できるようにするための堅実なドキュメントを構築できます。悲しいことに、XML はかなり肥大化していますが、概して、ほとんどの開発者は、すべての要約コンテンツを簡単に参照して、メソッド内の実際のコードを調べることができると思います。

于 2008-11-13T22:37:42.207 に答える
1

ジェフは、コメントについての非常に優れた記事を持っています (または、コメントではありません) ここで...

http://www.codinghorror.com/blog/archives/001150.html

質問に答えていないように見えることはわかっていますが、コードは可能な限り自己文書化する必要があるというのは妥当なポイントだと思います。

于 2008-11-13T21:08:26.457 に答える
1

それはすべてあなたの会社が使用している標準に依存しますが、私の乗組員のために、2番目の例のようにすべての関数の上部に文書化します(ちなみに、「/」キーを3回押すことでVisual Studio 2008でこれを行うことができますサブまたは関数の上部の行に!!)。

最初の例はやり過ぎです。特に、各行がコメント化されている下の数行です。ただし、ここでよく使用するため、関数のヘッダーにあるものは役立つかもしれないと思います。そして、他の多くのプログラマーから私が知る限り、それはいくぶん標準的であるように見えます。

于 2008-11-14T00:43:24.540 に答える
1

すべてのパブリック関数は、コード ベースにある程度精通している人が明確に理解できる必要がありますが、特定のセクションでは、コードを詳しく調べる必要はありません。

関数が何をするかを説明するために短い行を書く必要がある場合、関数/クラスの名前が不適切である可能性があります。その場合、名前は自明であるべきです

説明するために複数の短い文が必要な場合は、おそらく良いコメントです

段落が必要な場合は、名前が不明確である可能性が高いだけでなく、関数が多すぎる可能性があります。

通常、コメントの側で誤りを犯す方が良いでしょうIF YOU SURE SURE THEY ARE ACCURATE . 不正確および/または維持不可能なコメントは、コメントがないよりも悪いです

したがって、これらのルールを適用します。

最初の例では、「// 新しい顧客インスタンスを作成する」は冗長です。コードは非常に明確です。他のコメントは完璧です。それらは、コードが何を操作しているか/その結果が何であるかを明確にします

2番目の例では、コメントは無駄な労力であり、読みにくくなっています。関数に適切な名前を付けるだけです。その漠然とした「カウント」ではありません。それはネーミングが悪い。

于 2008-11-13T22:40:07.473 に答える
1

私が最近実施した調査によると、多くの仕様 (たとえば、「このメソッドは Y と Z を意味する X を実行する」など) の中に重要な「ディレクティブ」、たとえば、Caller は X を実行する必要がある場合、実際、読者は長いドキュメントを見ると、まとめて読むのをスキップします。

したがって、少なくとも、重要なものを分離するか、タグ付けを使用してください (Java を使用する場合は私に尋ねてください)。

于 2008-11-13T22:41:21.497 に答える
1

私は自分のコードですべてのパブリック メソッドを文書化する傾向があります。GhostDoc を使用すると、これは簡単になります。また、ソース コードを編集する際の煩雑さを軽減するために、通常は最初に "アウトライン モード" にしてコメントを折りたたむだけです (つまり、Visual Studio の [アウトライン] > [定義を折りたたむ] コマンドを使用します)。

私は Sandcastle を試したことはありませんが、XML でコメントしたメソッドに対して Intellisense が提供する快適さには本当に感謝しています。

于 2008-11-13T21:12:20.350 に答える
1

API ドキュメントを適切な形式 (通常は HTML) で閲覧できるのが好きなので、私は常に XML / Javadoc 形式のコメントを選びます。

実際のソース コードを参照する際には問題になりますが、Visual Studio は一般に、必要に応じて XML コメントを折りたたむことについてかなり賢いため、これは一般的に小さな問題であることがわかりました。

于 2008-11-13T21:13:18.490 に答える
1

繰り返さないでください。

  • 最初の例には、より適切なメソッド名があり、コメントがまったくないはずです。
  • 2 番目の例にはコメントを含めないでください。

最初のメソッドの名前は、新しいオブジェクトが割り当てられたことを反映する必要があります。

その動作が各 add のフレームワーク全体で標準である場合は、このメソッド API ドキュメントではなく、より高いレベルでドキュメント化する必要があります。それ以外の場合は、名前を変更してください。

コメントは情報を追加するものであって、ノイズの中に隠すものではありません。また、XML で必要な場合は、コメントが必要です。そして、彼らが付加価値を与える場所。

私は見たくありません:countという名前のメソッドの「カウントを返します」。

于 2008-11-13T21:26:25.657 に答える
0

ちなみに、「クリーンコード」(すばらしい本、ところで)によれば、ソースコードに埋め込まれているコメント内でHTML/XMLマークアップを使用することは避けるべきです。カーソルを合わせたときにIDEが気の利いたドキュメントを作成できる場合でも、ソースを参照するだけでは気が散りすぎて読めないと見なされます。

于 2008-11-13T22:57:53.960 に答える
0

自己コメント コードやメソッドのオーバーロードをコメントしないことを推奨するコーディング標準を見てきました。YMMV とはいえ、やり過ぎにつながる「Field _numberOfCars は車の台数を表す整数です」タイプのコメントから逃れるには良い方法のように思えます。

于 2008-11-13T21:16:04.087 に答える
0

ドキュメントを生成するためのヘッダー内のコメントは良いことです。コードにコメントを入れて、自分がしていることの理由を説明することも、通常は良いことです。あなたがしたことを言い換えて冗長なコメントを入れることは良いことではありません

于 2008-11-13T21:24:21.183 に答える
0

あなたが示したことは、あまりにも多くのことです。あなた自身の好意を持って、それを削除してください!

コードは、意味のあるメソッド名とパラメーター名を使用して、最初に自己文書化する必要があります。あなたが示した例では;

public Customer Add(Title Title, string FirstName, string MiddleInitial, string LastName) は、「カウント」と同様に、何が起こっているかを完全に理解できます。

あなたが指摘したように、このようなコメントは、そうでなければ読みやすいコードの周りの純粋なノイズです。ほとんどの開発者は、あいまいな自動生成された API ドキュメントを積み重ねるよりも、すぐにコードを調べて使用するようになります。毎回!

于 2008-11-13T21:30:43.883 に答える