4. Schreibweise von Membervariablen

Schreibweise von Membervariablen

  • ?

    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

    0
  • _

    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! 😉

    0
  • K

    Zeiger gibt es (fast) nicht in C# und Global geht in .Net nicht.

    0
  • ?

    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

    0
  • L

    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:

    0
  • ?

    Hallo

    Okay, ich war zu schnell und habe Mist geschrieben. Völliger Schwachfug, ich nehme des Satz zurück.

    chrische 😉

    0
  • _

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

    0
  • K

    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 😉

    0
  • _

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

    0
  • A

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

    0
  • K

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

    0

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

    0
  • ?

    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

    0

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

    0
  • ?

    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

    0
  • E

    unter cpp hab ich immer "m_" geschrieben, jetzt unter csharp schreib ich immer "_"
    das ist auch mitlerweile die einzigste kennzeichnung die ich ueberhaupt treffe

    variablen mit _ davor sind members, am sonsten sinds locale oder argumente (angemerkt bzgl referenzen usw)

    0
  • A

    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.

    Das ist Unsinn und löst auch nicht die genannten Probleme.

    Warum?
    Es ging doch um die Unterscheidung membervariablen und lokale Variablen. Wenn meine lokale Variable field, und meine Membervariable m_field heißt, meckert der Kompiler ebenso wenig wenn ich das m_ vergesse. Und dennoch ist es falsch.

    Hier sehe ich daher auch keinen Vorteil. Zudem kenne ich eure Programmierweise nicht. Aber ich hatte bislang nie die Probleme - trotz gleicher Benennung - Membervariablen von lokalen Variablen zu unterscheiden. Mag sein das irgendwer die Probleme hat weil er Romane als Funktionen betrachtet, oder Funktionen mit 1000den von Parametern hat. Weder das eine noch das andere halte ich für guten Stil.

    In einem Punkt gebe ich dir aber vollkommen recht:

    hustbaer schrieb:

    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.

    Wobei mir persönlich das am besten gefallen würde, was du als "nicht so gut" bezeichnest: Eine andere Einfärbung. Den Bezeichner verschandeln halte ich persönlich für schlechter Lesbarer (Ich brauche etwas länger um einen Code mit Präfixen zu lesen, als einen ohne).

    cu André

    0
  • K

    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!

    Wie soll er das erzwingen können ?

    0
  • ?

    Knuddlbaer schrieb:

    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!

    Wie soll er das erzwingen können ?

    Wenn man ohne 'this' nicht kompilieren kann, muss man zwangsläufig 'this' hinschreiben...^^

    oder ich hab deine Frage nicht verstanden!

    Grüße

    0
  • ?
     

    class Klasse
{
  private int feld = 0;

  int TuWas()
  {
    int feld = 1;

    return feld + 1;
  }
}

    Erklär mir mal wie du hier erzwingen willst, dass man 'this' benutzen muss.
    Klar, man könnte sagen lokale Veriablen dürfen nicht den gleichen Namen wie eine Membervariable haben, allerdings finde ich das keine gute Lösung.

    PS: Auch beim _-Anstatz meckert der Compiler nicht, allerdings ist imho schneller ersichtlich ob es sich um eine lokale oder eine Membervariable handelt, da diese Information Teil des Variablennamens ist.

    0
Anmelden zum Antworten