frage zu coding styles

[asc]

pepe75 schrieb:

wir haben in unserer firma diverse leute, die der meinung sind member variablen einer klasse muessten kein prefix m_ besitzen und koennten benamst werden wie man gerade lustig...

Sehe ich genauso. Variablen sollten nach ihrer Aufgabe benannt werden, und nicht mit irgendwelchen kryptischen Zusätzen ergänzt werden. Man kann über das m_ noch streiten, spätestens wenn irgendwer heutzutage noch die Ungarische Notation in einer Sprache aufführt, die eigene Typen zulässt hört es aber definitiv auf.

Zumal das m_ auch nicht sonderlich nötig ist, wenn man grundsätzlich versucht Methoden kurz und übersichtlich (=> leichter zu warten) zu halten, und ich bin der Meinung das selbst ein this-> lesbarer aussagt was gemeint ist, wenn den mal eine Unterscheidung nötig wird.

Aber ansonsten sei hier vielleicht nur einmal das Buch "C++ Coding Standards - 101 Rules, Guidelines, and Best Practives" von den Autoren Herb Sutter und Andrei Alexandrescu (Die beide eigentlich als C++ Gurus gelten) genannt.

[asc]

pepe75 schrieb:

was waeren in euren augen vor- nachteile diesbezueglich und was zu praeferieren

Das hängt sehr von der persönlichen Meinung ab, aber Grundsätzlich sollte Code leicht und möglichst fließend gelesen werden können (Ich persönlich stolpere beim Lesen über solche Präfixe, andere mögen damit kein Problem haben).

Lesbaren Code erzeugt man in erster Linie durch folgendes:
1. Tendenziell kurze Funktionen/Methoden schreiben, lieber eine lange Funktion in logische Einzelheiten spalten. Klassen ebenso nicht zu groß werden lassen, und lieber auch mal splitten.
2. Codeteilen immer nur eine Aufgabe geben.
3. Tiefe Verschachtelungen meiden.
4. Variablen und Funktionen möglichst sprechend, und nach ihren Aufgaben benennen.

Und wenn man sich daran hält, stellt man häufig fest das irgendwelche Präfixe oder Postfixe recht unnötig werden (und bei manchen sogar zu einem stockenden Lesefluss führen). Zudem habe ich festgestellt, das Typinformationen seltener, als die eigentliche Aufgabe einer Variablen, beim Lesen nötig ist.

[pumuckl]

pepe75 schrieb:

was waeren in euren augen vor- nachteile diesbezueglich und was zu praeferieren !?!?

Vorteil: Wenn du mal in einer weniger komfortablen IDE unterwegs bist, siehst du trotzdem, dass es eine Membervariable ist.

Nachteil:

1. Es stört den Lesefluss. m_strAddrPlz und ähnliche Namen lesen sich holprig. Vielleicht ist man das von Sourcecode nicht anders gewohnt, es geht aber auch deutlich glatter. (Siehe Zitat in meiner Signatur ;))
2. Wenn du drauf angewiesen bist, durch soetwas daran erinnert zu werden, dass eine Variable eine Membervariable ist, dann hast du in dem Kontext eventuell einfach zu viele Namen/Variablen. In einer 10-Zeilen Funktion kann man die 5 lokalen Variablen und 10 Klassenvariablen auch ohne Präfixe gut auseinanderhalten. Wenn man allerdings eine 200-Zeilen-Funktion mit 60 lokalen Variablen hat und die Klasse dazu nochmal 120 Membervariablen beisteuert ist klar, dass man den Überblick verliert. Dann sollte man aber nicht mit Präfixen die Symptome mindern sondern mit Refactoring die Ursache beheben.
3. du stellst beim Refactoring fest, dass die lokalen Variablen, die du in verschiedenen Methoden benutzt, zu einer einzigen Membervariable gemacht werden sollten, um zwischen verschiedenen Funktionsaufrufen Informationen zu behalten. Das Ergebnis ist, dass du vor den Variablennamen überall ein m_ setzen musst. In der komfortablen IDE kein Problem, aber da brauchst du den Präfix ja wie du schon sagtest eh nicht. In der Unkomfortablen IDE darfst du das per Hand machen. Viel Spaß...

[Fellhuhn]

Freu dich über das m_, denn das ist noch simpel.

Wenn es dann noch f_ für Funktionsparameter und a_ für lokale Variablen gibt, gekoppelt mit mp_ für Memberpointer oder mpp_ für Memberpointerpointer bzw mdp_ für Memberpointer die im Designer (Qt) definiert wurden... ... ...

Das schreit nach Axt.

[volkard]

pepe75 schrieb:

hallo ich haette mal ein frage in bezug auf coding-standards (C++).
diese frage richtet sich besonders an erfahrene leute.

ich moechte mein problem an einem einfachen beispiel vorstellen:

wir haben in unserer firma diverse leute, die der meinung sind member variablen einer klasse muessten kein prefix m_ besitzen und koennten benamst werden wie man gerade lustig ist denn schliesslich zeigt einem ja eine anstaendige IDE durch entsprechendes syntax highlighting an dass es sich um eine member variable handelt.

jetzt fehlen einem (mir) bei solch einer (nach meinem geschmack etwas blau-aeugigen) argumentationsweise etwas die worte.

was waeren in euren augen vor- nachteile diesbezueglich und was zu praeferieren !?!?

vielen dank vorab.

Hallo!
Ich hätte mal ein Frage in Bezug auf Posting-Standards (deutsch).
Diese Frage richtet sich besonders an erfahrene Leute.

Ich moechte mein Problem an einem einfachen Beispiel vorstellen:

Wir haben in unserem Forum diverse Leute, die der Meinung sind, Wörter müßten keine Großbuchstaben oder Umlaute haben, und Kommas könnten weggelassen werden, wie man gerade lustig ist, denn schliesslich versteht man die Sättze auch so.

Jetzt fehlen einem (mir) bei solch einer (nach meinem Geschmack etwas blau-aeugigen) Argumentationsweise etwas die Worte.

Was wären in euren Augen diesbezueglich die Vor- und Nachteile und was wäre zu praeferieren?

Vielen dank im Voraus.

[brotbernd]

volkard schrieb:

Hallo!
Ich hätte mal ein Frage in Bezug auf Posting-Standards (deutsch).

Was ist denn das für eine anständige IDE, die Membervariablen highlighted? Ich leb wohl mal wieder hinterm Mond.

[Dravere]

Vorteil vom Präfix m_ :
- Autovervollständigung zeigt einem gleich alle Membervariablen, wenn man nur das Präfix eingibt.
- Man hat eine Konsistenz drin, wenn sich mal Lokal- und Membervariablen überschneiden.

Ich finde es schrecklick, wenn man wegen einer Überschneidung an einem Ort, plötzlich this-> verwenden und ansonsten nirgends. Sieht einfach nur unschön aus. Als Alternative sehe ich durchaus das ständige verwenden von this-> , was mir persönlich aber einfach nicht so gefällt. Das Präfix m_ stört mich nicht und ich bin daran gewöhnt. Daher sehe ich grundsätzlich keine Nachteile darin.

Ist allerdings das einzige Präfix, welches ich verwende.

Grüssli

[Werner Salomon]

In dem Umfeld, in dem ich arbeite, werden Membervariablen i.A. mit dem Prefix 'm_'. Das finde ich in Ordnung, da ich es ja nicht anders gewöhnt bin, und mir fehlt auch was, wenn das Prefix fehlt. Zum Beispiel

Klasse::Klasse( int anzahl, double farbe )
    : anzahl( anzahl )
    , farbe( farbe )
{}

das ist syntaktisch ok, aber irgendwie schwer zu lesen; insbesondere wenn da noch etwas Code drumherum steht.

Das Argument 'Ungarische Notation ist auch doof' zieht hier gar nicht. Die Ungarische Notation bezeichnet den Typ einer Variablen und das 'm_' - oder auch eine andere Kennzeichnung - bezeichnet den Scope der Variablen. Das ist etwas ganz anderes und letzteres finde ich auch hilfreich.

asc schrieb:

Aber ansonsten sei hier vielleicht nur einmal das Buch "C++ Coding Standards - 101 Rules, Guidelines, and Best Practives" von den Autoren Herb Sutter und Andrei Alexandrescu (Die beide eigentlich als C++ Gurus gelten) genannt.

kann ich auch wärmstens empfehlen ... auch auf die Gefahr hin, dass da drin steht, dass das 'm_' unnötig ist .

Gruß
Werner

[pumuckl]

Werner Salomon schrieb:

kann ich auch wärmstens empfehlen ... auch auf die Gefahr hin, dass da drin steht, dass das 'm_' unnötig ist

Richtig - das steht da drin

[Dravere]

Übrigens:

pumuckl schrieb:

3. du stellst beim Refactoring fest, dass die lokalen Variablen, die du in verschiedenen Methoden benutzt, zu einer einzigen Membervariable gemacht werden sollten, um zwischen verschiedenen Funktionsaufrufen Informationen zu behalten. Das Ergebnis ist, dass du vor den Variablennamen überall ein m_ setzen musst. In der komfortablen IDE kein Problem, aber da brauchst du den Präfix ja wie du schon sagtest eh nicht. In der Unkomfortablen IDE darfst du das per Hand machen. Viel Spaß...

Immer diese Argumentation mit der nicht komfortablen IDE. Wer sagt dir denn, dass du nicht zusätzliche Werkzeuge benutzen darfst? Abgesehen mal davon, dass fast jede IDE mindestens ein Search&Replace bietet. Falls sie das wirklich nicht hat, dann könntest du halt auch mal einen externen Editor dafür hernehmen. Da reicht ja sogar Notepad

Grüssli

[asc]

pumuckl schrieb:

Werner Salomon schrieb:

kann ich auch wärmstens empfehlen ... auch auf die Gefahr hin, dass da drin steht, dass das 'm_' unnötig ist

Richtig - das steht da drin

Nein, steht es nicht (Siehe Artikel 0).

C++ Coding Standards schrieb:

0. Don't sweat the small stuff.
(Or: Know what not to standardize)
...
Don't overlegislate naming, but do use a consistent naming convention...
...(If you can't decide on your own naming convention, try this one: ... name private member variables likeThis_...)...

Und ob man nun einen Postfix oder einen Präfix angibt, ändert nichts, ebenso wenig wie hier sehr viel persönlicher Geschmack ist. Man sollte es bei der Benennung nicht übertreiben (ich sehe das "m_" usw. als fehl am Platze an - aber das ist persönliche Meinung). Das wichtigste bei allem ist im Endeffekt die Konsistenz.

Es gibt Regeln die bedeutend wichtiger als die Diskussion über dieses Präfix, oder das fehlen Selbigen sind. Wichtiger ist z.B. die Lesbarkeit und Wartbarkeit des Codes. Und ich für mich habe halt festgestellt, das wenn ich auf letzteres achte (z.B. durch kurze Funktionen...) es keinen wesentlichen Grund dafür gibt.

[asc]

Dravere schrieb:

Übrigens:
...
Immer diese Argumentation mit der nicht komfortablen IDE. Wer sagt dir denn, dass du nicht zusätzliche Werkzeuge benutzen darfst? Abgesehen mal davon, dass fast jede IDE mindestens ein Search&Replace bietet.

Die "Search&Replace" Werkzeuge mancher IDEs kann man in die Tonne treten, gerade wenn man z.B. in vielen Klassen bestimmte Variablennamen hat, und dies von der IDE nicht unterschieden werden kann (was wiederum alle mir bekannten Refactoringtools können). Ein Ersetzen kann in diesem Fall recht aufwendig werden, vor allem wenn die Typauflösung recht langsam ist...

Und bestimmte IDEs lassen sich auch nicht sinnvoll erweitern (Ich habe bis heute kein Refactoringwerkzeug für den C++ Builder gesehen. Und dies muss noch nicht mal viel können, das einzige eingebaute funktioniert jedenfalls nicht).

[volkard]

"Refactoring" ist total überbewertet.

[pumuckl]

asc schrieb:

pumuckl schrieb:

Werner Salomon schrieb:

kann ich auch wärmstens empfehlen ... auch auf die Gefahr hin, dass da drin steht, dass das 'm_' unnötig ist

Richtig - das steht da drin

Nein, steht es nicht (Siehe Artikel 0).

Hu, dann hab ich mich da im Buch vertan...

[Dravere]

asc schrieb:

Die "Search&Replace" Werkzeuge mancher IDEs kann man in die Tonne treten, gerade wenn man z.B. in vielen Klassen bestimmte Variablennamen hat, und dies von der IDE nicht unterschieden werden kann (was wiederum alle mir bekannten Refactoringtools können). Ein Ersetzen kann in diesem Fall recht aufwendig werden, vor allem wenn die Typauflösung recht langsam ist...

Verstehe die Argumentation nicht ganz. Es ging um das Umbenennen von Variablen in einer Klasse. Wen man pro Header- und Implementierungs-File nur eine Klasse hat, was zum Beispiel bei mir der Fall ist, muss man das Search & Replace halt auf das File beschränken. Das Search & Replace muss somit nicht Klassen unterscheiden können. Und was du plötzlich mit der Typauflösung meinst ... absolut keine Ahnung, was du damit nun meinst. Ich glaube, dass du bereits ein Refactoring-Tool meinst, ich meine aber das simple Suchen und Ersetzen von zum Beispiel Notepad

Grüssli

[loks]

Muss mal das Buch raussuchen aus dem der Satz stammt, aber fan dich gut:

"Schlechte Programmierer diskutieren stundenlang über naming-conventions während sich gute Programmierer einfach auf eine einigen und mit der eigendlichen Arbeit weitermachen".

Der Consens on vielen Büchern die ich bisher zu dem Thema gelesen habe war, daß es unterm Strich egal ist welche Naming-Convention man benutzt, hauptsache man benutzt sie einheitlich.

[Fellhuhn]

Ich nehm als Prefix immer den momentanen Wochentag. In welcher Sprache wird mit einem Würfel festgelegt.

[knivil]

volkard schrieb:

"Refactoring" ist total überbewertet.

Sehe ich genauso. Auch ist Refactoring (was meist nur Suchen & Ersetzen bedeutet) ein schlechtes Argument fuer Programmierstile. Persoenlich verwende ich einen Unterstrich (_) am Ende bei Membervariablen.

[pepe75]

@volkard:

ehrlich gesagt wundern mich die antworten etwas.
ich habe eher probleme beim lesen von code von anderen wenn ich alle naselang ueberlegen muss ob eine variable eine member ist oder nicht. ganz besonders schoen wird es dann wie in folgendem fall:

class A
{
  public:
    void Do(long x)
    {
      y = 'a';
      x = 5;
      // hier noch mehrere dutzend zeilen code ...
      short y = 10;
    }
  private:
    long x;
    char y;
};

Fuer dieses kleine Beispiel mag es zwar dem geuebten auge einfach erscheinen zu erkennen was gemeint ist, allerdings bei komplizierterem code (wie in der praxis) ist es muehsamer solche zusammenhaenge im kopf rekunstruieren zu muessen als ein m_ zu lesen.
aber das scheint geschmacksache zu sein.

sich auf eine IDE verlassen (uebrigens hierbei ist beispielhaft NetBeans gemeint gewesen), die mir farbig anzeigt, ob es sich um eine member handelt oder nicht, finde ich auch nicht richtig.

[asc]

knivil schrieb:

volkard schrieb:

"Refactoring" ist total überbewertet.

Sehe ich genauso. Auch ist Refactoring (was meist nur Suchen & Ersetzen bedeutet) ein schlechtes Argument fuer Programmierstile.

1. Bedeutet Refactoring weit mehr als Umbenennen und Suchen/Ersetzen (auch wenn es einen Teil darstellt).

2. Kristallisiert sich manchmal später ein besserer Name für Variablen, Methoden etc. heraus, und es erhöht die Lesbarkeit dann auch den besseren Namen zu übernehmen. Und spätestens bei der öffentlichen Schnittstelle einer Klasse reicht ein einfaches Suchen&Ersetzen nicht mehr.

3. Ändert sich Code im Laufe der Zeit, aus einer ursprünglich kurzen Methode wird eine längere etc. Dann ist es an der Zeit auch wieder etwas aufzuräumen, gerade wenn das Projekt lange Zeit gepflegt werden soll.

Und gerade ein echtes Refactoringwerkzeug kann in diesen Fällen sehr viel Zeit sparen. z.B. in einer großen Methode ein Stück markieren das man auslagern will, Methodenname angeben und automatisch eine neue Methode mit den nötigen Eingangs- und Ausgangsgrößen erstellen... Alles was dazu dient einen Code wartbar zu halten und gleichzeitig Zeit zu sparen ist mit Sicherheit nicht verkehrt.