XMLドキュメントのコメントには何を含める必要がありますか?


13

特にクラスメンバーのXMLコメントに関しては、コードをより適切に文書化することを目指していますが、多くの場合、それは愚かなことです。

イベントハンドラーの場合、命名規則とパラメーターは標準的で明確です。

/// <summary>
/// Handler for myCollection's CollectionChanged Event.
/// </summary>
/// <param name="sender">Event Sender</param>
/// <param name="e">Event Arguments</param>
private void myCollection_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
    // actual code here...
}

また、要約が冗長になるように、明確に名前が付けられた単純なプロパティ(IMO)も頻繁にあります。

/// <summary>
/// Indicates if an item is selected.
/// </summary>
public bool ItemIsSelected
{ get { return (SelectedItem != null); } }

そのようなコメントは、宣言自体がまだ伝えていない情報を追加しないとは思わない。一般的な知恵は、コードを繰り返すコメントは書かずに残すことが最善であると思われる。

明らかに、XMLドキュメンテーションは、通常のインラインコードコメント以上のものであり、理想的には100%の範囲を網羅しています。そのような場合、何書くべきですか?これらの例に問題がなければ、私が今評価していないかもしれないという付加価値はありますか?


6
「そして、理想的には100%のカバー率を持つ」 -それは非常に議論の余地がある。私は、インテリセンスのポップアップ専用のタイプのパブリックインターフェイスでそれらが好きですが、プライベートメソッドでは単純に冗長すぎるIMO
Ed S.

3
100%のカバレッジは、プライベートメソッド、特にイベントハンドラーには適用されません。
SLaks

1
GhostDocがドキュメントを書いてくれます。「何をしGetData()ますか」と尋ねますか?Gets the dataもちろん、それはもちろんです!
デヴィン・バーク

2
@ジャスティン:GhostDocはかなりクールに見えます。拾うかもしれません。

1
@ジャスティン:引数、私はGhostDocが嫌いです-最初は素晴らしいようですが、しばらくすると、通常は古いコードに戻ってそれが何をするかを理解する必要があるときに、自動生成されたコメントを1マイル離れて見つけることができることに気付きます。すべてのXMLコメントを非常に簡単にできますが、それらのコメントに実際の情報が含まれていることを保証するものではありません。GhostDocを使用すると良い出発点が得られますが、名前と署名を一目見ただけでは理解できなかった怠け者を簡単に除外できます。
キース

回答:


10

XML docコメントは、公開メンバーを対象としています。

コンパイラの警告は、これを明確に述べています:

一般公開されているタイプまたはメンバー「Type_or_Member」のXMLコメントがありません

プライベートメンバーにXMLコメントを追加する必要があるのは、それらのメンバーが名前から明らかでない場合のみです。


6

ここでは純粋な意見ですので、それが価値があると考えてください。

余分なxmlコメントは嫌いです。メソッド/プロパティ名にスペースを追加するだけのゴーストドキュメントスタイルの場合は二重です。それは価値を追加せず、単に実際のコードの私の見解を混乱させます。

何か明確にする必要がある場合は、必ずコメントしてください。ただし、意味のある名前の小さな焦点を絞った方法によって、多くの明確さが伝わります。コードを改善してコメントを不要にできる場合は、コードにコメントを付けないでください。

でも私は、不要の使用を開始してはいけないthis.Me.

副次的な注意事項として、XMLコメントの可視性を切り替えることができるVisual Studioアドインが必要です。(ヒントヒント)


this.何らかの理由で、Microsoftの公式ガイドラインでは、ローカル変数とインスタンスprivate変数にまったく同じ命名規則を使用することを推奨しているため、事態は始まったのではないかと思います。それはひどく欠陥のあるスタイル、IMOです-場合によっては、StackOverflowExceptionin property から1本の太った指で離れているsetMyProperty = MyProperty;、コンストラクタパラメータの代わりにフィールドがゼロに初期化され、Microsoftさえm_ほとんどの時間を内部で使用し続けました。
-jrh

2

@SLaksが述べたように、公開メンバーでは、XMLドキュメントはかなり冗長で完全でなければなりません。

ただし、Visual Studioがインテリセンスを生成し、XMLドキュメントコメントでツールチップを支援するため、プライベートメンバー、保護メンバー、または内部メンバーでも非常に役立ちます。

この意味は:

// describe what this does
private void DoSomething() 
{
    // or describe it here...

完全に十分なドキュメントかもしれませんが、次のとおりです。

/// <summary>describe what this does</summary>
private void DoSomething() 
{

コードのどこからでもすぐに見やすくなります。

一般に、私はAPIの外部ユーザー向けに書いているパブリックXMLコメント、および私やチームの他のユーザー向けに書いている内部XMLコメントについて。

パラメータの説明をスキップすることは、前者にとってはおそらく悪い考えであり、後者にとっては素晴らしいことです。

私はいつもかどうかは、(特にパブリックAPIドキュメントで)追加するgetか、setプロパティに:

/// <summary>Gets a value indicating whether an item is selected.</summary>
public bool ItemIsSelected
{ 
    get { return SelectedItem != null; } 
}

C#のインテリセンスからは利用可能かどうgetsetは明らかではありませんが、XMLコメントに含めると、ツールチップから一目でわかるようになります。


依存します。あなたは何を持っている場合public getが、internal set財産としての?どのようにコメントしますか?:
ギヨーム

1
@GuillaumeはXMLコメントが公開されているので、XML getをドキュメント化しset、通常の//コメントでドキュメント化します。
キース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.