frage zu coding styles

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