C# - Wie schreibt man private variablen richtig?

4 Antworten

Wenn du mit einem Tool wie ReSharper arbeitest, wirst du bei Bezeichnern schnell darauf hingewiesen, dass nach Konvention private Felder mit einem führenden Unterstrich beginnen:

private int _someField;

und nur statische Felder mit konstanten Werten eine Ausnahme bilden:

private const int SomeField = 1;
private static readonly int SomeOtherField = 2;

Dabei richtet sich das Tool laut diesem Artikel standardmäßig nach den Microsoft Guidelines.

In diesen lässt sich allerdings keine Vorgabe für private Felder finden. Nur dies:

The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines, and public or protected instance fields are not allowed by the  member design guidelines.
✔️ DO use PascalCasing in field names.
✔️ DO name fields using a noun, noun phrase, or adjective.
❌ DO NOT use a prefix for field names.
For example, do not use "g_" or "s_" to indicate static fields.

Microsoft Design Guidelines

(Weitere Guidelines zu C# / .NET findest du übrigens hier).

Weiterhin spricht man sich in den generellen Namenskonventionen gegen Unterstriche in Bezeichnern aus:

❌ DO NOT use underscores, hyphens, or any other nonalphanumeric characters.

und bei Verwendung eines MS Tools wie StyleCop würden führende Unterstriche ebenfalls als Verstoß angemerkt werden.

All dem widersprechen wiederum die Konventionen, auf die sich das Team für das .NET-Subprojekt CoreFX geeinigt hat:

We use _camelCase for internal and private fields and use readonly where possible. Prefix instance fields with _, static fields with s_ and thread static fields with t_. When used on static fields, readonly should come after static (i.e. static readonly not readonly static).

Quelle

Du merkst: Von offizieller Seite gibt es keine eindeutige Vorgabe, wie private Felder aussehen sollen und hinzu kommen unterschiedliche Ansichten bezüglich des Unterstrichs (der ursprünglich übrigens seinen Ursprung aus C++ haben sollte und in einer Sprache wie Dart sogar Bestandteil der Syntax ist).

Meiner Erfahrung nach ist die Verwendung des führenden Unterstrichs unter C#-Entwicklern weit verbreitet. Ich selbst bevorzuge sie.

Ob du dich dieser Konvention anschließt oder es so, wie in Java machst, ist also deine Entscheidung (bzw. solltest du mit den Entwicklern abstimmen, mit denen du womöglich zusammenarbeitest). Eine Pflicht ist der Unterstrich jedenfalls nicht.

Technisch gesehen:

Vollkommen egal. Du könntest auch

private string Gu_Te_FrA_gE;

schreiben, wenns dir gefällt.

Allerdings gibt es gewisse Konventionen (also "wie es üblich ist"-Dinge), und da sind im Grunde beide von dir erwähnten Schreibweisen "korrekt".

P.S.: Ich persönlich würde trotzdem die Schreibweise ohne Unterstrich vorziehen, ausser in Fällen in denen es mit "notwendig" ist.

Moin,

das mit dem Unterstrich ist nur eine Schreibweise, wie man auch gerne

bBool oder iInt schreibt.

Kannst also beides nach Bedarf nutzen und haben nichts mit der Funktionalität zu tun.

LG

Woher ich das weiß:Berufserfahrung – 💻 Zertifizierter Sr. Cloud Engineer im IT-Consulting

Das bleibt jedem selbst überlassen und ist eine Frage des Geschmacks.

Die Guideline von Microsoft und die allermeisten C#-Entwickler sind sich aber einig: Variante 2

Außerdem sollte keine einzige Klassenvariable jemals nicht private sein, dafür gibt es Properties.

Woher ich das weiß:Berufserfahrung – C#.NET Senior Softwareentwickler

regex9  26.05.2020, 19:42
Die Guideline von Microsoft (...)

Kannst du auf die konkrete Stelle bitte einmal verlinken? Ich habe eben noch selbst diesbezüglich gesucht, bin aber nicht fündig geworden.

0
Palladin007  26.05.2020, 20:02
@regex9

Da muss ich zugeben: Ich hab sie nie gelesen :D

Ich hab vor Jahren Mal eine Guideline meiner damaligen Firma gelesen, die wurde damals auf der Grundlage von Microsoft erstellt und für die eigenen Anforderungen angepasst.
Außerdem hab ich sehr oft gelesen, dass MS das so empfiehlt, selber gelesen habe ich es aber nie.

Aus irgendeinem Grund sind sich da aber die allermeisten C#-Entwickler einig, eine andere Erklärung, als eine (ehemalige) Guideline von Microsoft hab ich nicht.

So auf die Schnelle hab ich mehrere MSDN-Artikel zu dem Thema gefunden, aber nichts zum Thema globaler Variablen, keine Ahnung, warum nicht.

0
Palladin007  26.05.2020, 20:07
@regex9

PS:

https://en.wikipedia.org/wiki/Naming_convention_(programming)#C.23

The most common practice is to use PascalCase for the names of all fields, except for those which are private (and neither const nor static), which are given names that use camelCase preceded by a single underscore; for example, _totalCount.

Vielleicht stand das Mal in der Guideline und sie haben es aus irgendeinem Grund entfernt.

1
regex9  26.05.2020, 21:18
@Palladin007

Das glaube ich auch. Das würde erklären, wieso auch ReSharper diese Konvention bei sich integriert hat.

0
Palladin007  26.05.2020, 21:53
@regex9

Dann frage ich mich, wieso sie das entfernt haben?

Die Community führt es ja mehrheitlich weiter.

Interessant ist dabei auch, dass der alte Code von Microsoft meist mit "m_" beginnt, bei neuem Code (am Beispiel vom Immutable-Namespace) ist es aber nur der Unterstrich.

0
regex9  27.05.2020, 09:29
@Palladin007

Da spielt einiges an Geschichte / Verlauf technischer Entwicklung hinein.

Charles Simonyi galt als Begründer der ungarischen Notation, die ursprünglich konkret für die Programmiersprache BCPL entwickelt wurde. In den 70er Jahren baute Simonyi noch für das Unternehmen Xerox PARC an Software, die auf BCPL basierte. Später (in den 80ern) wechselte er zu Microsoft und war an dem Entwicklungsprozess der Office-Software (Excel, Word, ...) beteiligt. In diesem Zuge führte er auch seinen Style-Guide ein, der sich generell schnell verbreitete und z.B. auch Anwendung für VB oder die Windows API fand. Allerdings kam es dabei auch zu Missinterpretationen dieser Konvention und das war letztendlich einer der Auslöser, wieso die ungarische Notation so negativ betrachtet wird.

Die m_-Notation ist jedenfalls Teil der ungarischen Konvention / dieses Style Guides. Siehe beispielsweise in den Styleguide für die Windows API.

Ein anderer Grund für die Verbreitung wird der Entwicklungsstand von Entwicklungsumgebungen / Editoren gewesen sein. Heute gibt dir die IDE via Syntax Highlighting, Hovering, etc. massenweise Informationen, wie Element für Element zu interpretieren sind und welchen Typ man vorliegen hat. Damals war man noch nicht soweit und so behalf man sich mit solchen Konzepten.

Gehalten hat sich die Notationsweise dann lediglich noch über Gewohnheitstierchen und das generelle Problem, dass der Code nun mal schon geschrieben war. Code Refactoring z.B. für die Windows API kannst du nicht so einfach bringen. 😁

Aber inzwischen hat sich ja einiges getan. Zum einen hat sich Visual Studio immer weiter entwickelt. Zum anderen war gerade Hejlsberg ja viel an einem konsistenten .NET Framework gelegen und die langwierig ausgeknobelten Entscheidungen wurden später von Cwalina und Abrams in Framework Design Guidelines (2005) zusammengefasst. Das sollte eines der einschneidensten Werke gewesen sein, nur drei Jahre später hat R. C. Martin mit Clean Code nachgelegt. Beide Werke richten sich gegen die ungarische Notation.

Zu dem führenden Unterstrich: Sein tatsächlicher Ursprung rührt daher, dass damit Elemente gekennzeichnet werden sollten, die nicht öffentlich zur Verfügung stehen / keine Relevanz nach außen haben, also interne Elemente sind. Ein gutes Beispiel noch heute (in C#): Ungenutzte Variablen werden von Resharper angekreidet, außer, man benennt sie nur mit einem Unterstrich. Da Microsoft viele C++-Entwickler hat, dürfte von ihnen dieser Einfluss herrühren und generell wird er ja fortgeführt / auch in anderen Sprachen genutzt. In Scala oder Clojure finden sich z.B. solche Vorgehensweisen (Unterstrich wird ignoriert). Python verwendet gern führende Unterstriche für Elemente, auf die kein Zugriff bestehen soll und setzt teilweise sogar mehrere führende Unterstriche ein.

Wieso Microsoft den Punkt zu privaten Feldern ausgelassen hat, verstehe ich auch nicht. Vielleicht war es ein zu großer (interner) Streitpunkt.

0