frage zu coding styles

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.

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.

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

Janjan

Er hat wohl noch nie was von Divide&Conquer gehört. $:\$

asc

zmomg schrieb:

asc schrieb:

...in einer großen Methode ein Stück markieren ...Methodenname angeben und automatisch eine neue Methode mit den nötigen Eingangs- und Ausgangsgrößen erstellen...

Und das soll anständig funktionieren? Darauf würde ich mich nie verlassen.

Es funktioniert.

zmomg schrieb:

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

Oh... da muss ich aber schnell eine neue Erkenntnis bekommen, ich programmiere seit 18 Jahren. Zumal ich nicht nur die Größen von Methoden/Funktionen versuche überschaubar zu halten, sondern auch Klassen etc.

rüdiger

Wie schon gesagt ist das ganze Geschmackssache und alles hat Vor-/Nachteile. Das ganze endet oft in ziemlich fundamentalen Glaubenskriegen und oft ist es die verschwendete Zeit einfach nicht wert.

m_ hat zB den Nachteil, dass es mit Autovervollständigung nicht so schön ist. (_m-Suffix hilft dagegen und markiert immer noch. Aber ist dann auch nicht mehr so deutlich zu lesen). Im Grunde kann man aber ohnehin sagen, dass ein Klassendesign nicht optimal ist, wenn man so viele Member hat, dass man diese nicht mehr eindeutig zuordnen kann/kennt.

Dravere

rüdiger schrieb:

m_ hat zB den Nachteil, dass es mit Autovervollständigung nicht so schön ist.

Inwiefern? Würde mich mal interessieren, wieso jemand dies als unschön sieht.

Grüssli

Nexus

asc schrieb:

Aber da hilft auch kein "m_" für die Lesbarkeit.

Nimmst du in den zweideutigen Fällen (z.B. Setter) immer ein this-> ? Finde ich persönlich auch nicht so schön.

asc schrieb:

Bei mir werden Membervariablen nicht farblich hervorgehoben, aber bei einer üblichen Methodenlänge unter 20 Zeilen, erkennt man dies auch ohne Präfix direkt.

Nun gut, die 20 Zeilen sind ohnehin ein Ideal, bei dessen strikter Durchfühung nicht selten unübersichtlicherer Code entsteht... So zumindest meine Erfahrung. Natürlich ist es gut, kurze Funktionen zu haben, aber man sollte das nicht zu eng sehen. Gerade mit Kommentaren oder Auftrennung einer Anweisung auf mehrere Zeilen ist diese Grenze schneller erreicht als wirklich sinnvoll. Zu viele Funktionen, von denen jede fast nichts tut, können sich auch kontraproduktiv auswirken.

Und ich finde schon, dass ein "m_" oder "my" vor dem Bezeichner hilft, die Zugehörigkeit schneller zu erkennen. Aber das ist wohl wirklich Ansichtssache...

Nexus schrieb:

Nimmst du in den zweideutigen Fällen (z.B. Setter) immer ein this-> ? Finde ich persönlich auch nicht so schön.

Oiso i find des suppa

asc

Nexus schrieb:

asc schrieb:

Aber da hilft auch kein "m_" für die Lesbarkeit.

Nimmst du in den zweideutigen Fällen (z.B. Setter) immer ein this-> ? Finde ich persönlich auch nicht so schön.

Finde ich jedenfalls verständlicher, gerade für jemanden der neu ist (Jegliche Präfixe/Postfixe unterliegen den persönlichen Vorlieben derer, die eine Regel aufstellen).

Nexus schrieb:

asc schrieb:

Bei mir werden Membervariablen nicht farblich hervorgehoben, aber bei einer üblichen Methodenlänge unter 20 Zeilen, erkennt man dies auch ohne Präfix direkt.

Nun gut, die 20 Zeilen sind ohnehin ein Ideal, bei dessen strikter Durchfühung nicht selten unübersichtlicherer Code entsteht... So zumindest meine Erfahrung.

Zum einen habe ich nicht ohne Grund "üblich" verwendet, Ausnahmen gibt es sicherlich, aber zum anderen habe ich bislang noch kaum eine Stelle gefunden wo das Trennen nicht der Übersicht diente. Sei es eine komplexere if-Bedingung durch eine Methode ersetzt, die einen passenden Namen hat ("Is..."), oder sei es bestimmte Schleifen zu trennen, wenn die Verschachtelung zu tief wird.

Davon abgesehen: Kommentare verwende ich zwar auch, aber fast ausschließlich im Header und für Doxygen. Nur selten muss wirklich etwas im Code erklärt werden (Vorausgesetzt die Methodennamen sind aussagekräftig ;p).

Nexus schrieb:

Und ich finde schon, dass ein "m_" oder "my" vor dem Bezeichner hilft, die Zugehörigkeit schneller zu erkennen. Aber das ist wohl wirklich Ansichtssache...

Ja, es gibt definitiv wichtigeres.

pumuckl

Dravere schrieb:

rüdiger schrieb:

m_ hat zB den Nachteil, dass es mit Autovervollständigung nicht so schön ist.

Inwiefern? Würde mich mal interessieren, wieso jemand dies als unschön sieht.

Weil ich mir nach zwei Anschlägen eine von 10 Membervariablen raussuchen muss statt nach einem Anschlag nur 3 Variablen zur Auswahl zu haben

Dravere

pumuckl schrieb:

Dravere schrieb:

rüdiger schrieb:

m_ hat zB den Nachteil, dass es mit Autovervollständigung nicht so schön ist.

Inwiefern? Würde mich mal interessieren, wieso jemand dies als unschön sieht.

Weil ich mir nach zwei Anschlägen eine von 10 Membervariablen raussuchen muss statt nach einem Anschlag nur 3 Variablen zur Auswahl zu haben

Also nach einem Anschlag, habe ich nicht nur noch 3 Variablen. Vor allem kommen da auch alle Funktionen, Makros, usw. usf. mit rein. Und wenn du mit einer fremden Bibliothek, wenn möglich noch eine C Bibliothek, arbeitest, dann ist das definitiv nicht der Fall. Allerdings wenn ich mir überlege, dass ich mit 7 Tasten pro Sekunde tippe, dann dürfte dies wirklich kein Problem machen

Grüssli

wenn Du ein Problem mit der Unterscheidung zwischen Membern und globalen Variablen hast, empfehle ich dir "this->"