Wie benennen Sie Ihre privaten Variablen in C #? [geschlossen]

Was ist die bewährte Methode, die am häufigsten akzeptierten Namenskonventionen für private Variablen in C #?

1. private int myInteger;
2. private int MyInteger;
3. private int mMyInteger;
4. private int _myInteger;
5. private int _MyInteger;
6. Mysteriöse andere Option

Welches verwenden Sie und warum? (Mein Unternehmen ist ziemlich neu in C # und ich möchte die branchenweit am meisten akzeptierte Methode auswählen, um in unseren Codierungsstandard einzusteigen.)

In den Entwurfsrichtlinien für MSDN-Klassen http://msdn.microsoft.com/en-us/library/ta31s3bc.aspx wird Option 1 - myInteger empfohlen.

Ich habe diesen Stil immer benutzt. Ich habe eine persönliche Abneigung gegen den _-Charakter.

Ich benutze Option 4 oben:

private int _myInteger;

Ich möchte einen Hinweis auf den Gültigkeitsbereich in meinen Variablennamen haben, und der Unterstrich reicht für diesen Zweck aus. Es ist auch ziemlich einfach zu lesen.

Ich benutze das folgende Namensschema:

• 1st (myInteger) für Variablen mit lokalem Gültigkeitsbereich
• 2nd (MyInteger) für öffentliche Eigenschaften
• 4. (_myInteger) für private Variablen

Ich denke, die Option 4 ist wirklich die am besten lesbare Option. Es hilft Ihnen dabei, dies zu tun:

public Person(string name, int age) 
{
    this.name = name;
    this.age = age;
}

Es macht auch alle privaten Mitglieder auffälliger. Woher kommt der Teufel im folgenden Beispiel age? Ohne die thisQualifikation ist es schwerer zu sagen.

private void Method()
{
    var x = 2;
    var y = age + x;
}

Das ist viel einfacher zu verstehen:

private void Method()
{
    var x = 2;
    var y = _age + x;
}

PascalCasing ist in der Regel für öffentliche Eigenschaften, Konstanten, Methoden usw. der Klasse reserviert. Also würde ich 2 und 5 überspringen.

Zweitens wird von der ungarischen Notation in der .NET-Welt abgeraten, sodass (ähm, ich denke) 3 richtig ist. Angenommen, das ist was mit 3 los ist.

Das geht mit camelCasing und _camelCasing. Normalerweise verwende ich _camelCasing für Klassenvariablen und normales altes camelCasing für Variablen, die auf eine Methode oder eine engere Ebene beschränkt sind. Camel-Gehäuse ist der akzeptierte Standard für Methodenargumente, geschützte / private Variablennamen und Variablen innerhalb einer Methode oder eines engeren Bereichs.

Ich stelle auch gerne den Unterstrich voran, damit meine privaten Variablen in meinem Intellisense gruppiert sind. Ich mache dies jedoch nur für Variablen, die einem Typ zugeordnet sind. Variablen, die innerhalb einer Methode oder eines engeren Bereichs deklariert wurden, lassen den Unterstrich weg. Vereinfacht die Trennung und das Zusammenhalten weniger verwendeter Variablen.

private int integer

Wenn Sie in einem Methodenbereich zwischen Member- und lokalen Variablen verwechseln, müssen Sie wahrscheinlich eine Umgestaltung vornehmen.

Ich glaube, der beste Weg, dies zu tun (in C # / .net), ist eine Kombination aus 2 und 6:

private int MyInteger { get; set; }

Hier gibt es theoretisch überhaupt keine Variable, aber sie sieht aus und verhält sich wie eine private Instanzvariable. Wenn wir diesem Wert eine Geschäftslogik hinzufügen müssen (es ist ein vollständig interner Wert, damit wir alles tun können, was wir wollen), dann ist er bereits für uns "eigensinnig". Ein heißer, dampfender Pokal des Gewinns!

Ich mache Option 4, weil die SSCLI so aussieht, aber ehrlich gesagt ist mir die Benennung von privaten Variablen egal. Öffentlichkeit ist eine andere Geschichte.

Übrigens hast du m_MyInteger vergessen

Ich würde es nicht "mein" nennen!

Aber ich würde sagen

class C
{
     int VariableName { get; set; }
}

Das ist oftmals besser als explizite Variablen. Wenn ich eine explizite private Variable hätte, würde ich es aufrufenint _variableName;

In C ++ verwende ich _ häufig, wenn ich den Editor wechsle, wodurch ich nicht erkennen kann, ob es privat ist.

Bei C # neige ich dazu, _ wegzulassen, da Visual Studio es mir ermöglicht, zu prüfen, ob es privat ist.

Ich neige dazu, die Camel Case-Methode zu verwenden, um dies zu tun.

Ich benutze 4 ( private int _myInteger;) weil:

private int myInteger;

So benenne ich meine lokalen Variablen.

private int MyInteger;

So benenne ich Konstanten.

private int mMyInteger;

Dies ist kein C # -Stil.

private int _MyInteger;

Das sieht komisch aus.

mit dem Unterstrich.

Bill Wagner erklärt, warum in Effective C # . Aber ich würde nie eine ganze Zahl nennen meine Integer , besser etwas wie _age oder _length. Das Einfügen des TypeName in den Instanznamen ist eine schreckliche Praxis. Namen sollten selbsterklärend sein und da C # typensicher ist, können Typen jederzeit ermittelt werden.

Sie müssen ein genaueres Beispiel geben, aber:

private int count, private int badFileCount,private static readonly int ReconnectAttemptsLimit

Übrigens erhalten Sie all dies KOSTENLOS, wenn Sie die neueste und beste Version installieren und verwenden MSFT Stylecop.

Ich gehe nach Option 5: private int _MyFoo

Ich sehe allerdings keinen wirklichen Wettbewerbsvorteil gegenüber _myFoo.

Verwenden Sie camelCasing für private Variablen wie myInteger

Berücksichtigen Sie ein vorangestelltes Argument, _wenn die Variable eine Sicherung für eine Eigenschaft ist, um Verwirrungen zu
vermeiden. Variable _myPropertyfür EigenschaftMyProperty

Ich habe ReSharper meine Variablen genannt, nicht nur meine, sondern auch alle anderen. Während des Projekts herrscht ein hohes Maß an Konsistenz.

Der IDesign C # -Codierungsstandard von Juval Lowy ist sehr beliebt. Diese Norm empfiehlt, privaten Mitgliedsvariablen das Präfix "m_" (Option 6) voranzustellen. Das machen wir in unserem Team.

private int m_myInteger;

Option 4 ( _myInteger) ist eine akzeptable Abwandlung dieser Norm.

Die MSDN-Empfehlung ( myInteger) hat mir nicht gefallen , da es schwierig ist, ein privates Mitglied von einer lokalen Variablen zu unterscheiden. Ihre Empfehlung löst natürlich dieses Problem, indem sie private Mitglieder mit qualifiziert this, was mir überflüssig erscheint.