Ist das "Gets or Sets .." in der XML-Dokumentation von Eigenschaften erforderlich?


19

Ich suche eine Empfehlung für eine bewährte Methode für XML-Kommentare in C #. Wenn Sie eine Eigenschaft erstellen, hat die erwartete XML-Dokumentation anscheinend die folgende Form:

/// <summary>
/// Gets or sets the ID the uniquely identifies this <see cref="User" /> instance.
/// </summary>
public int ID {
    get;
    set;
}

Da die Signatur der Eigenschaft jedoch bereits angibt, welche Operationen für die externen Clients der Klasse verfügbar sind (in diesem Fall sind es beides getund set), sind die Kommentare meiner Meinung nach zu gesprächig, und möglicherweise würde Folgendes ausreichen:

/// <summary>
/// ID that uniquely identifies this <see cref="User" /> instance.
/// </summary>
public int ID {
    get;
    set;
}

Microsoft verwendet das erste Formular, sodass es sich anscheinend um eine implizite Konvention handelt. Aber ich denke, dass der zweite aus den von mir genannten Gründen besser ist.

Ich verstehe, dass diese Aussage geeignet ist, als nicht konstruktiv eingestuft zu werden, aber die Menge an Eigenschaften, die man kommentieren muss, ist riesig, und deshalb glaube ich, dass diese Frage das Recht hat, hier zu sein.

Ich werde alle Ideen oder Links zu offiziellen empfohlenen Praktiken zu schätzen wissen.


Ehrlich gesagt ist das einzige, was mir der Kommentar gibt, das nicht im Code enthalten ist (vorausgesetzt, dies ist ein Mitglied von User), dass die ID eindeutig ist. deshalb ist nichts davon 'notwendig'.
jk.

@Tomas - hast du das GhostDoc Plugin installiert ? Es generiert gute XML-Kommentare für Sie, wenn Sie zunächst gute Eigenschaftennamen verwenden und die gets or setsoder getsabhängig von den Eigenschaftenzugriffsberechtigten automatisch einfügen.
Trevor Pilley

@ Trevor - Ich habe es installiert. Ich habe nur darüber nachgedacht, ob ich die Vorlagen ändern und die "Gets or Sets" entfernen soll oder nicht :). Es ist allerdings ein großartiges Plugin.
Tomas

Willkommen in der Welt der Undokumentation .
Colonel Panic

Antworten:


28

Die Signatur kann anderen Codeteilen mitteilen, welche Operationen verfügbar sind. Sie werden dem Codierer jedoch nicht eindeutig angezeigt, während er oder sie arbeitet, und die XML-Dokumentation ist für Benutzer gedacht und nicht für Compiler.

Nehmen Sie diese Klasse zum Beispiel:

public class MyClass
{
    /// <summary>
    /// The first one
    /// </summary>
    public int GetOrSet { get; set; }

    /// <summary>
    /// The second one
    /// </summary>
    public int GetOnly { get; private set; }

    /// <summary>
    /// The last one
    /// </summary>
    public int SetOnly { set; private get; }
}

Wenn Intellisense aufgerufen wird, um auf eine dieser Eigenschaften zuzugreifen, gibt es keine Angabe, in welche Eigenschaften geschrieben, von denen gelesen oder von beiden gelesen werden kann:

Bildbeschreibung hier eingeben

Auch beim Betrachten der Dokumentation sind wir uns nicht ganz sicher:

Bildbeschreibung hier eingeben Bildbeschreibung hier eingeben Bildbeschreibung hier eingeben

Als solche fügen wir die gets oder sets , gets oder sets hinzu , um dem Programmierer das Schreiben des Codes zu erleichtern. Es wäre sicherlich nicht das Schreiben eines großen Codeblocks, der einige Daten liest und verarbeitet, nur um festzustellen, dass Sie diese Daten nicht wie erwartet in die Eigenschaft zurückschreiben können.

Bildbeschreibung hier eingeben


Vielen Dank für eine gründliche Antwort. Ich denke, dass dies leider Einschränkungen der Visual Studio IDE sind. Ich habe darüber nachgedacht und denke, dass der Intellisense Ihnen zeigen könnte, welche Eigenschaften z. B. getnur im aktuellen Kontext vorhanden sind. Es ist nicht sehr praktisch, die Dokumentation an eine bestimmte Entwicklungsumgebung anzupassen. Dennoch denke ich, dass Visual Studio und C # so eng miteinander verbunden sind, dass dies möglicherweise die richtige Lösung ist.
Tomas

1
@Tomas Ich stimme zu, dass Visual Studio einen größeren Unterschied machen sollte. Es freut mich natürlich, wenn ich in dem Moment, in dem ich das Grundstück nicht richtig benutze, eine rote Schnur bekomme.
Mike

2

StyleCop verwendet die Gets or Sets ...Notation, die es mit der Regel SA1623 erzwingt .

Die verlinkte Seite listet einen anderen Fall auf, den Sie nicht aufgelistet haben:

/// <summary>
/// Gets a value indicating whether the item is enabled.
/// </summary>
public bool Enabled
{
    get { return this.enabled; }
}

Die andere Option, die Sie auflisten, wäre.

/// <summary>
/// ID that uniquely identifies this <see cref="User" /> instance.
/// </summary>
public int ID { get; set; }

vs

/// <summary>
/// ID that uniquely identifies this <see cref="User" /> instance.
/// </summary>
public int ID { get; }

Was im Intellisense-Hinweis, dass die Eigenschaft schreibgeschützt ist, keine Informationen liefern würde, könnten Sie sich auch für diesen Fall eine Konvention einfallen lassen Gets ..., Gets or Sets...aber die Aufgabe ist gut, imo.

Es gibt auch andere in der StyleCop-Regel aufgelistete Varianten, die durch die Verwendung von, Gets or Sets...jedoch möglicherweise nicht ohne, deutlich werden.

Auch beim Generieren von Dokumentation aus Doxygen oder Sandcastle würde die vollständige Notation die API (zum Beispiel) besser dokumentieren.


2

Das einzige Mal, dass ich Informationen zum Abrufen und Festlegen einer Eigenschaft in den XML-Kommentaren hinzufüge, ist, wenn sie sich nicht wie erwartet verhält (direktes öffentliches Abrufen und Festlegen).

Wenn sie privat sind oder zusätzliche Logik enthalten, erwähne ich sie, ansonsten dokumentiere ich nur die Absicht der Eigenschaft.


1

Ich wäre glücklicher mit der ausführlicheren Version.

Der andere ist wie der Kommentar "Inkrementzähler", nachdem eine Zählervariable inkrementiert wurde.

Es ist offensichtlich, dass es ein Get and Set gibt. Wenn Sie einen privaten Setter hätten, wäre dies offensichtlich, da Sie das Schlüsselwort private hätten.

Kommentare sollten einen Mehrwert bieten und nicht nur eine Kommentarversion des eigentlichen Codes sein.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.