Schreibweise von Membervariablen

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

EXDW

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)

asc

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é

Knuddlbaer

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 ?

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

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.

O.o schrieb:

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.

Hehe, wusste gar nicht, dass das so geht :-P! Ob man dies erlaubt oder nicht, darüber lässt sich meines Erachtens streiten!
Aber in dem Fall ist es klar, da hast du recht.

Trotzdem bleibe ich dabei, dass man 'this' immer benutzen sollte. Es schaut einfach besser aus und signalisiert gleich die Klassenzugehörigkeit!

Grüße

Knuddlbaer

Hehe, wusste gar nicht, dass das so geht :-P!

Darum dreht es sich doch aber IMHO. Würde das nicht gehen, hätte man das Problem möglicherweise falscher Zuweisungen nicht.

_matze

Also ich habe lieber ein "m_" vor der Variable, als sie im Editor z.B. kursiv lesen zu müssen. Farben sind ja 'ne tolle Sache. Allerdings gibt es zu wenige Farben, die sich untereinander stark unterscheiden und einen guten Kontrast zu Weiß bilden, um alles damit erschlagen zu können. Fettdruck finde ich schon irgendwie komisch, und kursive Schrift im Code ist imo abartig! Zumindest bei mir beginnen da die Schwierigkeiten, den Code schnell lesen zu können, und nicht bei einigen, wenigen Präfixen...

hustbaer

Allerdings gibt es zu wenige Farben, die sich untereinander stark unterscheiden und einen guten Kontrast zu Weiß bilden, um alles damit erschlagen zu können.

Genau das finde ich auch.
Deswegen fände ich es praktisch wenn die IDE vielleicht irgendwelche Symbole einblenden könnte. Vor oder über/unter dem Bezeichner. Müsste man experimentieren was am besten lesbar ist und am wenigsten ablenkt.

Praktisch fände ich evtl. wenn man auch die Hintergrundfarbe pro "Typ" umstellen könnte.

Aber naja, zuerst bräuchte ich mal eine IDE die zuverlässig und schnell erkennt um was es sich bei einem Bezeichner handelt. Auch in grossen Programmen mit viel Namensräumen, auch wenn man ADL verwendet, auch wenn Templates im Spiel sind... nicht so einfach

_matze

hustbaer schrieb:

Deswegen fände ich es praktisch wenn die IDE vielleicht irgendwelche Symbole einblenden könnte. Vor oder über/unter dem Bezeichner. Müsste man experimentieren was am besten lesbar ist und am wenigsten ablenkt.

Hört sich im Grunde gar nicht schlecht an. Trotzdem würde ich da erst mal Angst haben, dass sich der Screen vor lauter Mini-Symbolen in eines dieser Bildchen verwandelt, auf denen man angeblich was sieht, wenn man lange genug auf einen imaginären Punkt dahinter starrt. Sowas steht und fällt eben mit der Umsetzung...

F98

Meine Definition erfolgt so:

public class Test1
{
    private double _dValue = 0.0;
    private string _sCaption = string.empty;

    public double Value
    {
       get
       {
          return _dValue;
       }
    }

    public string Caption
    {
       get
       {
          return _sCaption;
       }
    }

    public Test1(double dValue, string sCaption)
    {
        _dValue = dValue;
        _sCaption = sCaption;
    }
}

Privates mit Unterstrich, Publics als Property und lokale Variablen immer ohne Unterstrich. So weis man bescheid.

EXDW

aber mit _d oder _s ? sieht ja grausig aus

asc

Meine im Gegenvergleich so (was glaube ich auch die C# Empfehlung ist):

public class Test1
{
    private double number = 0.0;
    private string caption = string.empty;

    public double Number 
    {
       get
       {
          return number;
       }
    }

    public string Caption
    {
       get
       {
          return caption;
       }
    }

    public Test1(double number, string caption)
    {
        this.number  = number;
        this.caption = caption;
    }
}

Ich sehe keinen Vorteil mehr am "m_" und vergleichbaren, und von der UN (wie von F98 präferiert) bin ich noch länger weg. Wenn man nicht mehr ersehen kann was lokale Variablen und was Membervariablen sind, ist dies ein eindeutiges Indiz für zu lange Funktionen.

F98

Hm, das mit dem this ist schon ein Argument, ich persönlich finde es mit dem _ besser. Aber das kann man sehen wie Nolte, der sah es wie er wollte.

Hier mal meine Version:

public class Test1 { 
    private double p_Number = 0.0; 
    private string p_Caption = string.empty; 

    public double Number { 
       get { 
          return p_Number; 
       } 
    } 

    public string Caption { 
       get { 
          return p_Caption; 
       } 
    } 

    public Test1(double number, string caption) { 
        Number  = number; 
        Caption = caption; 
    } 
}

Membervariablen, Klassennamen immer großgeschrieben, Parameter, lokale Variablen immer klein angefangen (glaub nennt sich camelCase?). Private Member immer mit p_ davor.

F98

Noch so einer, der die Klammer "{" immer oben hinmacht

Jo, gleich schon viel übersichtlicher, gell?

Im Ernst: es gibt keinen einleuchtenden Grund, die schließende Klammer eines Blocks NICHT auf einer Ebene und ohne Füllzeile mit der "blockverursachenden" Zeile zu setzen.

void Blockverursacher() {
^  //----- Kommentar statt unnützer Füllzeile, sprich "{", ftw. ;)
.  int blubber = 0;
.  ...
.  ...
.  ...
.  ...
}

Bitte beachten: die obige Formatierung ist die Alleinseeligmachende. :xmas1: