it-swarm.com.de

Richtlinien zur Benennung von C # -Feldern?

Ich werde selbst an ein wenig C # -Code arbeiten, aber ich möchte sicherstellen, dass ich die am weitesten verbreiteten Namenskonventionen befolge, falls ich andere Entwickler einschalten, meinen Code freigeben oder meinen Code verkaufen möchte. Im Moment befolge ich die Namenskonvention, die Microsoft festgelegt hat, da sie am meisten akzeptiert zu sein scheint. Das einzige, was sie nicht erwähnen, ist das Benennen von privaten Feldern. Meistens habe ich gesehen, wie sie in camelCase wie geschützte Felder benannt wurden, die jedoch ein Problem darstellen, da Parameternamen in camelCase sein sollten. Nehmen Sie zum Beispiel den folgenden Konstruktor:

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

Wenn ich nun camelCase auch für private Felder verwende, gibt es einen Namenskonflikt, es sei denn, ich verwende "this", um auf die Klassenfelder zuzugreifen (was meiner Meinung nach gegen die meisten Standards verstößt, bedeutet mehr Tippen). Eine Lösung besteht darin, dem Parameter einen anderen Namen zu geben, aber es ist logisch nicht sinnvoll, denselben Daten 2 unterschiedliche Namen zu geben. Die einzige andere Lösung, von der ich weiß, dass sie in der C++ - Codierung üblich ist, ist, dass private Mitglieder am Anfang einen Unterstrich erhalten (_camelCase). Wird diese Lösung allgemein mit der C # -Codierung akzeptiert? Gibt es eine andere Lösung für dieses Problem (z. B. Verwendung von Eigenschaften (die PascalCase verwenden), um auf Felder zuzugreifen, sogar in der Klasse selbst)?

37
ryanzec

Befolgen Sie die Microsoft-Namensrichtlinien . Die Richtlinien für die Feldnutzung geben an, dass es camelCase sein sollte und nicht mit einem Präfix versehen werden sollte. Beachten Sie, dass die allgemeine Regel kein Präfix ist. Die spezifische Regel lautet nicht Präfix, um zwischen statischen und nicht statischen Feldern zu unterscheiden.

Wenden Sie kein Präfix auf Feldnamen oder statische Feldnamen an. Wenden Sie kein Präfix auf einen Feldnamen an, um zwischen statischen und nicht statischen Feldern zu unterscheiden. Das Anwenden eines Präfixes g_ oder s_ ist beispielsweise falsch.

und (von Allgemeine Namenskonventionen )

Verwenden Sie keine Unterstriche, Bindestriche oder andere nicht alphanumerische Zeichen.

EDIT: Ich werde feststellen, dass die Dokumente in Bezug auf private Felder nicht spezifisch sind, aber angeben, dass protected Felder nur camelCase sein sollten. Ich denke, Sie könnten daraus schließen, dass jede Konvention für private Felder akzeptabel ist. Sicherlich unterscheiden sich öffentliche statische Felder von geschützten (sie werden großgeschrieben). Meine persönliche Meinung ist, dass geschützte/private nicht ausreichend unterschiedlich sind, um unterschiedliche Namenskonventionen zu rechtfertigen, zumal Sie scheinbar nur von Parametern unterschieden werden. Das heißt, wenn Sie die Richtlinien für geschützte Felder befolgen, müssen Sie sie in dieser Hinsicht anders behandeln als private Felder, um sie von Parametern zu unterscheiden. Ich verwende this, wenn ich auf Klassenmitglieder innerhalb der Klasse verweise, um die Unterscheidung klarer zu machen.

EDIT 2

Ich habe die Konvention übernommen, die in meinem aktuellen Job verwendet wird, nämlich private Instanzvariablen mit einem Unterstrich voranstellen und generell nur geschützte Instanzvariablen als Eigenschaften mit PascalCase (normalerweise Autoproperties) verfügbar machen. Es war nicht meine persönliche Vorliebe, aber ich habe mich damit wohl gefühlt und werde wahrscheinlich folgen, bis etwas Besseres kommt.

35
tvanfosson

_camelCase für Felder ist aus dem, was ich gesehen habe, üblich (es ist das, was wir an unserer Stelle verwenden und Microsoft bevorzugt für .NET Framework ).

Meine persönliche Begründung für die Verwendung dieses Standards lautet, dass es einfacher ist, _ einzugeben, um ein privates Feld zu identifizieren, als this..

Zum Beispiel:

void Foo(String a, String b)
{
    _a = a;
    _b = b;
}

Versus

void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}

Ich finde das erste viel einfacher zu tippen und es verhindert, dass ich versehentlich dem Parameter mit dem Namen a anstelle von this.a..__ zuweist. Dies wird durch eine Code Analysis Maintainability-Regel verstärkt, die besagt:

  • CA1500 Variablennamen sollten nicht mit Feldnamen übereinstimmen.

Mein anderer Grund ist, dass this. optional ist (wenn Sie nicht mit einer lokalen Variablen oder einem Parameternamen kollidieren, wenn Sie nicht mit einer lokalen Variablen oder einem Parameternamen kollidieren, wird es schwieriger zu wissen, welche Variable Sie verwenden). Wenn Sie am Anfang aller privaten Felder einen _ haben, wissen Sie immer, welches ein Feld ist und welches lokalen Gültigkeitsbereich hat.

48
DaveShaw

Im Allgemeinen gibt es zwei weit verbreitete Möglichkeiten, Felder zu benennen (immer mit camelCase):

Unterstrich-Präfix verwenden

void F(String someValue) {
  _someValue = someValue;
}

Mit this. auf das Feld zugreifen und Namenskonflikte vermeiden

void F(String someValue) {
  this.someValue = someValue;
}

Persönlich bevorzuge ich später, aber ich werde die Konvention anwenden, die von der Organisation festgelegt wird, für die ich arbeite.

19

In unserem Shop starteten wir unser erstes C # -Projekt mit der von Microsoft vorgeschlagenen Richtlinie für private Mitglieder, d. H.

camelCaseFieldName

Wir gerieten jedoch bald in Verwirrung zwischen privaten Mitgliedern und Parametern und wechselten zu

_camelCaseFieldName

das hat für uns viel besser funktioniert.

Ein privates Mitglied hat normalerweise einen Zustand, der außerhalb eines Methodenaufrufs besteht. Der führende Unterstrich erinnert Sie daran.

Beachten Sie auch, dass die Verwendung der AutoVariable-Syntax für Eigenschaften die Notwendigkeit privater Sicherungsfelder, d. H.

public int PascalCaseFieldName { get; set;}

Für eine kurze Zusammenfassung von Nizza-Standards, die (meistens) den MS-Richtlinien folgen, besuchen Sie net-naming-conventions-and-programming-standards --- best-practices .

10
Tom Bushell

Philips Healthcare C # -Codierungsstandard

MSDN - Eric Gunnerson

Bearbeiten: Ich verwende dieses Schlüsselwort, um auf nicht statische Mitglieder in C # und Java zuzugreifen.

3
Deniz Acay

Das Wichtigste ist, einen Standard auszuwählen und dabei zu bleiben. Sehen Sie sich den C # -Codierungsstandard von iDesign unter IDesign an (ein Link auf der rechten Seite). Es ist ein großartiges Dokument, das beispielsweise Richtlinien für die Benennung enthält. Sie empfehlen die Verwendung von Kamel für lokale Variablen und Methodenargumente.

3
TLiebe

Wir verwenden StyleCop , um die Konsistenz im gesamten Code zu gewährleisten. StyleCop wird in Microsoft verwendet erzwingt gängige Best Practices für Layout, Lesbarkeit, Wartbarkeit und Dokumentation des C # -Quellcodes.

Sie können StyleCop während der Erstellung ausführen und Warnungen für Stilverletzungen generieren lassen.

Für die Beantwortung Ihrer spezifischen Frage sollten private Felder in camelCase und dem Präfix "this" vorangestellt sein.

2
John Myczek

Wie bereits erwähnt, umfassen Microsoft Naming Guidelines dose not private Felder und die Benennung lokaler Variablen. In Microsoft selbst findet man keine Konsistenz. Wenn Sie in Visual Studio Klassen- oder Einwegmuster generieren, wird so etwas erstellt

public MyClass(int value)
{
    this.value = value;
}

oder

private bool disposedValue = false; // To detect redundant calls

protected virtual void Dispose(bool disposing)
{
    if (!disposedValue)
    {
        ...
    }
}

Glücklicherweise wurde mehr und mehr Code von Microsoft geöffnet, also werfen wir einen Blick auf ihre Repos, z. ASP.NET Core MVC

private readonly IControllerActivator _controllerActivator;
private readonly IControllerPropertyActivator[] _propertyActivators;

Oder .NET Core

private T[] _array;

Sie können sagen, dass es nicht wirklich Microsoft ist, sondern .NET Foundation. Gut genug, werfen wir einen Blick auf Microsoft Repos :

private readonly MetricSeries zeroDimSeries;

Aber hier ist alte Microsoft-Implementierung von MVC

private IActionInvoker _actionInvoker;

Also es gibt keine gängige Praxis oder offizielle Richtlinie bezüglich der Benennung von privaten Feldern. Wählen Sie einfach eines aus, das Sie bevorzugen, und halten Sie sich daran.

2
Kosta_Arnorsky

Kurze Antwort: use _privateField, d. H. Führenden Unterstrich für private Felder verwenden.

Lange Antwort: hier geht es ...

Vor langer Zeit schlug Microsoft vor, camelCase für Felder zu verwenden. Siehe hier . Beachten Sie, wann dieses Dokument erstellt wurde, 22.10.2008. Ziemlich alt.

Die jüngste Codebasis von Microsoft zeigt jedoch ein anderes Bild.

  1. Schauen Sie sich den C # -Codierungsstil des .NET CoreFX-Github-Repositorys an. # 3 ist der Diskussionspunkt. Hier ist der relevante Teil

    Wir verwenden _camelCase für interne und private Felder und verwenden, falls möglich, readonly.

  2. Schauen Sie sich auch den Coding-Stil von Roslyn Repository an, der besagt, dass er den Konventionen von .NET CoreFX folgt.
  3. Schauen Sie sich noch einmal die .NET-Standardbeitragsseite an, auf der (zumindest für den Moment) auch angegeben ist, dass sie der gleichen Anleitung wie .NET CoreFX folgt.
  4. CoreCLR schlägt ebenfalls vor, dieselbe Anleitung wie CoreFX zu befolgen.
  5. Sogar Winforms repo spricht davon, denselben Standard zu verwenden.
  6. Ich glaube ich habe genug gesagt. Wenn Sie dem von Microsoft vorgeschlagenen Leitfaden folgen möchten, wissen Sie, was Sie tun müssen. Verwenden Sie führenden Unterstrich für private Felder wie folgt: _privateField.

Meine Meinung: Auch ich persönlich ziehe es vor, den Unterstrich für meine privaten Bereiche zu führen - macht es leicht zu unterscheiden, ohne die this zu benötigen.

1

Nach den Namenskonventionen von Microsoft sollte privaten Feldern ein Unterstrich vorangestellt werden.

Zum Beispiel:

private int _myValue;

Viel Glück!

1
Ian P

Die Konvention, die ich verwende, um zwischen privaten Klassenvariablen und Methodenparametern zu unterscheiden, lautet

private string baseName;
private string prefixName;
private string suffixName;

public GameItem(string baseName, string prefixName, string suffixName)
{
    this.baseName = baseName;
    this.prefixName = prefixName;
    this.suffixName = suffixName;
}
1
Dougc

Schauen Sie sich ReSharper an. Damit werden alle Stellen hervorgehoben, an denen Ihre Namen nicht den üblichen Richtlinien entsprechen. Darüber hinaus gibt es natürlich noch viele weitere Produktivitätssteigerungen.

0
Carlos

Ich mache das; es ist ziemlich im Einklang mit MSDN.

class MyClass : MyBaseClass, IMyInterface
{
    public event EventHandler MyEvent;
    int m_MyField = 1;
    int MyProperty {
        get {
            return m_MyField;
        }
        set {
            m_MyField = value;
        }
    }

    void MyMethod(int myParameter) {
        int _MyLocalVaraible = myParameter;
        MyProperty = _MyLocalVaraible;
        MyEvent(this, EventArgs.Empty);
    }
}

Hier ist ein bisschen mehr Detail: http://jerrytech.blogspot.com/2009/09/simple-c-naming-convention.html

0

Ich habe mit VB viel mehr gemacht als mit C #, also nehme ich an, dass ich einige Praktiken (Vorurteile?) Von der ersten zur letzten übertrage.

Ich mag es, dass die privaten Felder von Eigenschaften einen führenden Unterstrich haben - insbesondere in C # aufgrund der Berücksichtigung der Groß- und Kleinschreibung (deren Idee war that)? ihren Umfang zu verstärken.

Wenn Sie das nicht mögen, sind Sie wirklich das wird Ihnen nicht gefallen: Ich verwende im Allgemeinen auch Typpräfixe (außer bei Eigenschaftsfeldern) - "o" für Object, "s" für String, "i". für Ganzzahl usw.

Ich kann das nicht wirklich mit einem Peer-Review-Artikel oder irgendetwas verteidigen, aber es funktioniert für uns und bedeutet, dass wir nicht durch Verwirrung zwischen Gehäuse und Feld/Parametern stolpern.

So ...

Class MyClass

    Private msClassVariable  As String = ""

    Private _classProperty As Integer = 0
    Property Readonly ClassProperty() As Integer
        Get
            Return _classProperty
        End Get
    End Property

    Sub New()

        Dim bLocalVariable As Boolean = False
        if _classProperty < 0 Then _classProperty = 0
        msClassVariable  = _classProperty.ToString()
        bLocalVariable = _classProperty > 0
    End Sub

End Class
0
SteveCinq