frage zu coding styles

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

[asc]

pepe75 schrieb:

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.

Und spätestens wenn ich den Platzhalter "hier noch mehrere dutzend zeilen code" sehe, ist dies auch logisch. Aber da hilft auch kein "m_" für die Lesbarkeit. Bei mir werden Membervariablen nicht farblich hervorgehoben, aber bei einer üblichen Methodenlänge unter 20 Zeilen, erkennt man dies auch ohne Präfix direkt.

Ich habe die Erfahrung gemacht das Präfixe und Postfixe tendenziell nur über andere Probleme hinwegtäuschen.

[zmomg]

asc schrieb:

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.

Und das soll anständig funktionieren? Darauf würde ich mich nie verlassen. Außerdem ist es doch echt schon peinlich was ihr euch anscheißt wegen längeren Funktionen... "ZMOMG DIE FUNKTION HAT SCHON 300 ZEILEN, SCHNELL 5 MAL AUFSPLITTEN SONST BRENNT MEIN HIRN DURCH"
Gerade viele Funktionen machen alles UNübersichtlich , aber das müsst ihr erst noch erkennen. Ich geb euch 20 Jahre.

[pepe75]

@zmomg .. ich sehe da tickt einer wie ich

[Fellhuhn]

Unter 2000 Zeilen schreib ich erst gar keine Funktion.

[ipsec]

zmomg schrieb:

Gerade viele Funktionen machen alles UNübersichtlich , aber das müsst ihr erst noch erkennen. Ich geb euch 20 Jahre.

Würde ich nicht unterschtreichen. Oftmals hilft es beim Verständnis einer Funktion, wenn die einzelnen Aufgaben sinnvoll in Teilfunktionen trennt. Ein simples Beispiel:

double hypot(double a, double b)
{
    return sqrt(a*a+b*b);
}

Wenn hier sqrt nicht eine eigene Funktion wäre, würde es doch viel unübersichtlicher sein.