Unterstrichene Präfixe bei Mitgliedsvariablen. intellisense

Question

Jeder sagte, die "Unterstrich, kein Unterstrich" Debatte ist rein philosophisch und Benutzerpräferenz getrieben, aber mit intelli-sense mit dem Unterstrich können Sie Ihre Mitglied-Variablen von Ihrem lokalen Variablen sehr leicht zu unterscheiden und damit geben Sie einen konkreten Vorteil

Gibt es ein Gegenargument zu diesem Vorteil der Unterstriche für alle Mitgliedsvariablen?

Answer 1

Ja - für manche Menschen beeinträchtigt es die Lesbarkeit. Ich glaube, dass verschiedene Menschen auf unterschiedliche Weise lesen (manche vokalisieren innerlich, andere nicht). Für manche Menschen (mich eingeschlossen) unterbrechen Unterstriche den "Fluss" des Codes, wenn ich ihn lese.

Wenn Sie Schwierigkeiten haben, zwischen lokalen und Instanzvariablen zu unterscheiden, dann sind möglicherweise entweder Ihre Methoden zu groß oder Ihre Klasse tut zu viel. Das wird natürlich nicht immer der Fall sein, aber bei kurzen Klassen/Methoden finde ich das in der Regel kein Problem.

Answer 2

Wenn Sie nur die Intellisense wünschen, können Sie diese jederzeit durch Eingabe von " this. ".

OK, es sind 4 Zeichen mehr als "_", aber die Intellisense-Funktion zeigt Ihnen dann Ihre Mitglieder an.

Wenn Sie Unterstriche verwenden und Ihr Team Unterstriche verwendet, dann verwenden Sie diese auch weiterhin. Andere werden " m _", andere haben vielleicht andere Ideen. Ich verwende StyleCop und in meinem Team ist die Debatte beendet, wir verwenden " this ." und Präfixe im ungarischen Stil oder Unterstriche werden nicht verwendet. Und wir kümmern uns einfach nicht mehr darum.

[Dies ist keine Kritik an Ihrer Frage - es ist eine berechtigte Frage und sie ist es wert, gestellt zu werden - aber diese Debatte verschwendet viel zu viel Zeit bei Entwicklungsprojekten. Auch wenn ich nicht alles an StyleCop mag, benutze ich es gerne, da es diese Art von Debatten ausschließt. Im Ernst, ich habe schon an stundenlangen Meetings teilgenommen, in denen diese Art von Diskussion ein ganzes Entwicklungsteam beschäftigt hat. Verrückt. Wie gesagt, Ihre Frage ist berechtigt, aber bitte verschwenden Sie nicht Ihre eigene Zeit damit, sich darüber aufzuregen, das ist es nicht wert:-)

Answer 3

Die Verwendung von Unterstrichen ist nur eine Möglichkeit, diesen Effekt zu erzielen. Wichtig ist, dass Sie dabei konsequent vorgehen.

Answer 4

Der Unterstrich kann als eine Form der ungarischen Notation betrachtet werden * aber die Vorsilbe ist ein "magisches Zeichen" und nicht etwas, das eine Bedeutung hat.

Wenn Sie etwas wollen, das mehr darüber aussagt, wofür das Präfix steht, würden Sie ein Präfix verwenden wie member o mbr o m . Manchmal ist die Vorsilbe m_ verwendet wird, aber dann wird der Unterstrich als Trennzeichen und nicht als Teil des Präfixes verwendet, und die Benennungsempfehlungen für .NET besagen, dass er nicht als Trennzeichen verwendet werden sollte.

Ich persönlich mag den Unterstrich für Mitgliedsvariablen, auch wenn es ein Präfix mit einer versteckten Bedeutung ist. Es bringt die Namen nicht so sehr durcheinander, wie es ein anderes Präfix tun würde.

Und wie immer ist es wichtiger, sich für einen Standard zu entscheiden und sich daran zu halten, als für den Standard, den man tatsächlich wählt.

---

* Die ungarische Notation wird meist zur Angabe des Datentyps in schwach typisierten Sprachen wie VBScript verwendet, aber ursprünglich sollten damit andere Eigenschaften von Variablen angegeben werden, so dass die Verwendung für Mitgliedsvariablen eher den ursprünglichen Absichten entspricht.

Answer 5

Dies überall zu verwenden, verringert meiner Meinung nach die Lesbarkeit. Unterstrich-Präfixe für private Klassenfelder sind durchaus akzeptabel. Es ist kaum ungarisch, was eine wirklich schreckliche Namenskonvention ist und an der Intellisense-Front ist die Eingabe von _ plus einem Buchstaben ein extrem schneller Weg, um Ihre Liste aufzurufen. Ich verwende CSLA.NET und viele der BO-Beispiele verwenden die Unterstrich-Konvention und ich verwende sie auch weiterhin in meiner Arbeit. Lassen Sie sich von den ehemaligen C++- und C-Entwicklern der alten Schule nicht davon abschrecken, dass dies keine gute Praxis ist - .NET leidet nicht unter denselben Problemen. Ein gutes Beispiel ist die Übergabe von Argumenten in Konstruktoren:

public MyObject(int field1, int field2, int field3)
{
    _field1 = field1;
    _field2 = field2;
    _field3 = field3;
}

Meiner Meinung nach ist er viel lesbarer als

public MyObject(int field1, int field2, int field3)
{
    this.field1 = field1;
    this.field2 = field2;
    this.field3 = field3;
}

Aber das ist eine Frage des persönlichen Geschmacks, und wie schon an anderer Stelle gesagt wurde, ist Konsistenz das Wichtigste.