Schreibweise von Membervariablen
-
Wie ist eigentlich der generelle Konsens über die Schreibweise von Membervariablen in C#?
Funktionen und Properties werden in PascalCase geschrieben, lokale Variablen in camelCase. Interfaces mit I am Anfang, Exception-Klassen mit Exception am Ende. Event-Funktionen mit _ und dem Eventnamen dahinter usw. usf.
Gibt es auch eine Regel für Membervariablem? ist m_Variable noch aktuell oder wird hier was anderes genommen?
-
Guyy schrieb:
Gibt es auch eine Regel für Membervariablem? ist m_Variable noch aktuell oder wird hier was anderes genommen?
Nach dem Microsoft C#-Richtlinien (Ich suche sie aber jetzt nicht aus der MSDN), wird keinerlei Relikt aus der Ungarischen Notation, auch nicht "m_" mehr verwendet.
private int einWert; property EinWert...cu André
-
Das stellt aber ein Sicherheitsrisiko dar, da Parameternamen genauso geschrieben werden und man dann immer darauf achten muss, das this davor zu schreiben.
-
Hallo
Dann mach es halt anders. Üblich ist es aber nicht m_ oder ähnliches zu schreiben. Am Ende macht es eh jeder, wie er es will. Wenn du also m_ schreiben willst, steht dir das ja offen.
chrische
-
Guyy schrieb:
Das stellt aber ein Sicherheitsrisiko dar, da Parameternamen genauso geschrieben werden und man dann immer darauf achten muss, das this davor zu schreiben.
Was ist daran so schlimm ein this (das lesbarer als ein kryptisches "m_" ist) zu verwenden wenn es nötig ist? Ich sage nur wie es die Programmierkonvention von MS besagt (und verwende persönlich diesen Stil auch in C++).
cu André
-
asc schrieb:
Was ist daran so schlimm ein this (das lesbarer als ein kryptisches "m_" ist) zu verwenden wenn es nötig ist?
Tja, darum geht es ja gerade: Wenn man sich nicht gerade angewöhnt, das this immer zu schreiben (und wer will das schon?), dann kann man eben mal übersehen, dass es nötig ist, ein this zu schreiben und schon haben wir den Salat.
PS: Was hat m_ mit der Ungarischen Notation zu tun? Da ging es doch vor allem darum, dass der Variablentyp im Namen steht. Aber m_ hat doch nichts mit dem Variablentyp zu tun. Wenn das Ungarische Notation ist, ist dann die Praxis, vor jedes Interface ein I zu schreiben, nicht auch Ungarische Notation? Oder hinter jede Exception-Klasse ein "Exception"?
PPS: Weiß einer zufällig, wo diese Schreibweise für Membervariablen her ist:
int _member;bzw.
int _Member;bzw.
int member_;bzw.
int Member_;
-
Es ist halt mittlerweile guter Ton, auf der Ungarischen Notation 'rumzuhacken, das lässt sich wohl nicht mehr ändern. Dass es trotzdem viel kürzer, einfacher und ähnlich transparent ist, "m_" statt "this->" als Präfix zu verwenden, gilt da scheinbar nicht...
In meinen Augen haben solche Empfehlungen wahrscheinlich eher zur Folge, dass manche Anfänger ihre Member eben gar nicht mehr kennzeichnen...
Ich schreibe "m_" und schäme mich deswegen nicht!
EDIT: Und "m_" als kryptisch zu bezeichnen, ist doch stark übertrieben, oder? "!§$&/()=%" kannst du kryptisch nennen, "m_BodyCounter" nicht.
-
Tja, darum geht es ja gerade: Wenn man sich nicht gerade angewöhnt, das this immer zu schreiben (und wer will das schon?), dann kann man eben mal übersehen, dass es nötig ist, ein this zu schreiben und schon haben wir den Salat.
Das generiert mindestens eine Warnung durch den Compiler (und je nach Einstellung auch einen Fehler.)
Ansonsten kann man den Satz auch umbiegen wie es einem gerade in den Kram passt:
Wenn man sich nicht gerade angewöhnt, das <bitte Einsetzen> immer zu schreiben (und wer will das schon?), dann kann man eben mal übersehen, dass es nötig ist, ein <bitte Einsetzen> zu schreiben und schon haben wir den Salat.
-
Hallo
_matze schrieb:
Es ist halt mittlerweile guter Ton, auf der Ungarischen Notation 'rumzuhacken, das lässt sich wohl nicht mehr ändern. Dass es trotzdem viel kürzer, einfacher und ähnlich transparent ist, "m_" statt "this->" als Präfix zu verwenden, gilt da scheinbar nicht...
this muss man aber nicht immer schreiben, sondern wenn überhaupt nur wenn es gleichnamige Parameter gibt. Den Typen einer Variabel im Name zu haben, ist allerdings wirklich schlecht, aber dazu gibt es tausend Diskussionen...
_matze schrieb:
In meinen Augen haben solche Empfehlungen wahrscheinlich eher zur Folge, dass manche Anfänger ihre Member eben gar nicht mehr kennzeichnen...
Braucht man ja auch nicht. Warum soll man Membervariablen als solche kennzeichnen? Was soll das bringen?
_matze schrieb:
Ich schreibe "m_" und schäme mich deswegen nicht!
Brauchst du auch nicht, vor allem, weil es dir ja freisteht.
_matze schrieb:
EDIT: Und "m_" als kryptisch zu bezeichnen, ist doch stark übertrieben, oder? "!§$&/()=%" kannst du kryptisch nennen, "m_BodyCounter" nicht.
Ich halte m_auch nicht für kryptisch, aber sehr wohl für überflüssig.
chrische
-
Ich finde eine gewisse Kennzeichnung gar nicht verkehrt. Bei Pointer kommt ein "p" davor, so dass man das auch sieht, ohne mit der Maus drüber fahren zu müssen (und man sieht sich den Code ja vielleicht auch mal außerhalb der IDE an). Und wenn ich in einer Methode eine Variable sehe, möchte ich schon auf einen Blick sehen, on es Lokale oder Member ist. Würdest du also auch Globals nicht kennzeichnen?
In einem Punkt sind wir uns vermutlich einig. Sowas hier geht eher nicht:
g_pStrVarSobald der Präfix den Variablennamen in der Länge übertrumpft, ist Ende!
-
Zeiger gibt es (fast) nicht in C# und Global geht in .Net nicht.
-
Hallo
Wir sind hier doch .net, C# Forum, da wird nicht mit rohen Pointer gearbeitet. Globale Variablen habe ich noch nie gebraucht. Lokal oder Member? Es gibt nur Member.
chrische
-
chrische5 schrieb:
Lokal oder Member? Es gibt nur Member.
Ja, ich habe hier auf meiner Arbeitsstelle auch schon .NET-Code gesehen, in dem Schleifenzähler als Membervariablen definiert wurden.
:xmas1:
-
Hallo
Okay, ich war zu schnell und habe Mist geschrieben. Völliger Schwachfug, ich nehme des Satz zurück.
chrische
-
Oh, bin ja hier im C#-Forum! Insofern vergesst das mit den Pointern und Präfix "p" bzw. bezieht es auf C/C++. Obwohl es ja schließlich auch unsafe-Blöcke gibt, richtig? Aber dass die Sharpler gleich so radikal sind und auch Locals aus ihrem Code verbannen, war mir bislang noch nicht klar...
-
Lokale Variablen braucht man schon. Aber mal ehrlich, wenn man da ein l_ davor machen muss o.Ä. um zu wissen das diese Variable lokal ist, sollte die Methode doch ein wenig aufsplitten
-
Knuddlbaer schrieb:
Lokale Variablen braucht man schon. Aber mal ehrlich, wenn man da ein l_ davor machen muss o.Ä. um zu wissen das diese Variable lokal ist, sollte die Methode doch ein wenig aufsplitten
Und selbst bei Monster-Funktionen, sollten sie denn vorkommen, braucht man das nicht. Da greift schließlich das Ausschlussprinzip: g_ == global, m_ == Member, wenn's keins von beiden ist, wird es wohl eine lokale Variable sein...
-
_matze schrieb:
Da greift schließlich das Ausschlussprinzip: g_ == global, m_ == Member, wenn's keins von beiden ist, wird es wohl eine lokale Variable sein...
Was andere dadurch lösen das sie keine Präfixe, sondern kurze Funktionen verwenden. Dann stellt sich die Frage was lokal etc. ist garnicht.
-
_matze schrieb:
Knuddlbaer schrieb:
Lokale Variablen braucht man schon. Aber mal ehrlich, wenn man da ein l_ davor machen muss o.Ä. um zu wissen das diese Variable lokal ist, sollte die Methode doch ein wenig aufsplitten
Und selbst bei Monster-Funktionen, sollten sie denn vorkommen, braucht man das nicht. Da greift schließlich das Ausschlussprinzip: g_ == global, m_ == Member, wenn's keins von beiden ist, wird es wohl eine lokale Variable sein...
Ist p_ dann Pointer oder Parameter?!
-
Was ich öfters in C# Code sehe ist "_field" statt nur "field" oder "m_field" zu schreiben. Andere Varianten ("field_" etc.) hab' ich in freier Wildbahn noch nie gesehen.
Einfach nur "field" zu schreiben finde ich auch etwas verwirrend. Mir hilft es beim Lesen fremden Codes schon viel auf den ersten Blick zu wissen was ne Member-Variable ist und was nicht. Gerade wenn man Code nur schnell überfliegt. Die Unterscheidung Parameter vs. lokale Variable ist mir dabei nicht wichtig. (Parameter sind leicht zu finden - die Frage "Parameter oder nicht" lässt sich mit dem Blick auf eine einzige Zeile lösen -- die Frage "lokale Variable oder nicht" allerdings nicht)
Die Unterscheidung statische Member-Variable vs. nicht-statische ist dageben IMO sehr wichtig, allerdings hab' ich da bis jetzt in C# Projekten noch keine vernünftige Konvention gesehen. "s_" und "m_" finde ich praktisch. "s_" sieht aber vermutlich komisch aus wenn man nur "_" für nicht-statische Member verwendet.
