Schreibweise von Membervariablen

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

asc

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_;

_matze

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.

Knuddlbaer

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

_matze

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_pStrVar

Sobald der Präfix den Variablennamen in der Länge übertrumpft, ist Ende!

Knuddlbaer

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

LordJaxom

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

_matze

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...

Knuddlbaer

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

_matze

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...

asc

_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.

Knuddlbaer

_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?!

hustbaer

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.

hustbaer schrieb:

Einfach nur "field" zu schreiben finde ich auch etwas verwirrend.

Also wenn du damit die Unterscheidung "lokale vs. Membervariable meinst, dann gibt es dafür eine sehr einfache Lösung :-P! Einfach konsequent das 'this'-Schlüsselwort benutzen. Dadurch löst sich jegliches Problem!

hustbaer schrieb:

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.

Und würde auch hier 'this' bzw. der Klassenname benutzt werden um auf die Variablen zuzugreifen, würde sich dieses Problem auch nicht erst ergeben!

Die Konventionen wie m_variable oder g_variable sind sowieso dermaßen grausam und lassen den Code nur unnötig komplex aussehen!

Grüße

hustbaer

@StrictProgger: ein Problem am "this->" Ansatz (mal abgesehen davon dass es kacke aussieht), ist, dass der Compiler nicht schreit wenn man es mal weglässt.

Soll heissen: ein einfaches "field" statt "this->field" lässt der Compiler durchgehen, ein "field" statt "m_field" allerdings nicht. Effektiv bedeutet das dass du dich bei der "this->field" Variante nie darauf verlassen kannst, weil Programmierer faul und hinterhältig sind.

Die optimale Lösung wäre IMO garnix irgendwie zu kennzeichnen, und IDEs zu verwenden die das zuverlässig erkennen und anzeigen. Seis nun über Farbe/Kursiv/Fettdruck (nicht so gut), oder irgendwelche kleinen Symbole vor/neben/über/... den Bezeichnern (besser), oder irgendeine andere Möglichkeit das schön darzustellen.

hustbaer schrieb:

@StrictProgger: ein Problem am "this->" Ansatz (mal abgesehen davon dass es kacke aussieht), ...

Also dieser Meinung bin ich ehrlich gesagt überhaupt nicht. IMO sieht es sauber und ordentlich aus!

hustbaer schrieb:

Soll heissen: ein einfaches "field" statt "this->field" lässt der Compiler durchgehen, ein "field" statt "m_field" allerdings nicht. Effektiv bedeutet das dass du dich bei der "this->field" Variante nie darauf verlassen kannst, weil Programmierer faul und hinterhältig sind.

Hier stimme ich dir schon eher zu!
Wobei Dummheit (also meines Erachtens Dummheit :-P) IMO bestraft werden sollte. Ich finde es so ein Unding das 'this' wegzulassen.
Es hilft einem echt viel, wenn man über den Code fliegt und erkennt wie die Klasse bzw. das Objekt aufgebaut ist!

Um das Problem mit dem "lockeren" Compiler zu lösen, würde ich ihn einfach so scharf schalten, dass er eben sowas nicht mehr durchgehen lässt und ALLE Programmierer sozusagen dazu zwingt, 'this' zu benutzen!
Irgendwo muss man auf einen gemeinsamen Zweig kommen. Dann hätte u.a. die IDE auch wieder weniger Arbeit :-), weil es einheitlich geregelt wäre!

Grüße