Wie findet ihr einen solchen Code-Stil?

[asc]

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Auch wenn ich mich selbst nicht 100%ig daran halte, sind Funktions-/Methodenrümpfe die auf eine Bildschirmseite passen deutlich lesbarer, als solche die sehr lang sind - Egal aus welchem Grund. Was das Auge mit einem Blick umfassen kann ist einfach lesbarer. Ist etwa so wie ein Text mit oder ohne einzelnen Abschnitten.

cu André

[pumuckl]

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Nur wenn es mehr als halb so viele cases wie Zeilen auf dem Bildschirm gibt.

[C++Fan 2009]

asc schrieb:

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Wenn man OO benutzt um ein effizientes Sprachmittel wie switch Anweisungen zu umgehen, macht man was falsch.

[Shade Of Mine]

C++Fan 2009 schrieb:

asc schrieb:

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Wenn man OO benutzt um ein effizientes Sprachmittel wie switch Anweisungen zu umgehen, macht man was falsch.

Nein.

Die meisten switches sind durch dynamisches dispatching ideal zu loesen. Natuerlich gibt es Faelle wo ein switch einfach das beste ist - aber es tut nicht weh vor jedem switch sich darueber gedanken zu machen. Denn idR ist das switch nur eine auspraegung von vergessener dynamik (die nicht zwangslaeufig ueber OO implementiert werden muss).

[C++Fan 2009]

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Shade Of Mine schrieb:

Denn idR ist das switch nur eine auspraegung von vergessener dynamik.

Kannst Du das genauer darstellen? Was meinst Du mit "vergessener Dynamik"?

[volkard]

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Denn idR ist das switch nur eine auspraegung von vergessener dynamik.

Kannst Du das genauer darstellen? Was meinst Du mit "vergessener Dynamik"?

zum beispiel die tastendispatchmonster

switch(key)
{
  case 'X': moveBack(); break;
  case 'A': moveLeft(); break;
  case 'D': moveRight(); break;
...
}

statt

(*keyToAction[key])();

der benutzer wünsch sich doch eh, daß er dynamisch die tasten neuzuweisen kann.

oder

switch(mob.mobType)
{
  case TROLL: runAway(); break;
  case GOBLIN: kill(mob); break;
  case ...
}

aber dafür (zum tun von was bestimmtem abhängig vom typ) gibts virtuelle methoden.

[asc]

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Zum Einen ist der Overhead meines Erachtens nicht so wesentlich wie du es hier darstellst. Zudem gewinnt man an Flexibilität und Wartbarkeit. Es mag sein das in deinen Anwendung jeder Prozessortakt zählt, aber in meinen Anwendungsbereich ist Geschwindigkeit zwar nicht unwichtig, aber auch nicht das Hauptaugenmerk wenn man mit etwas Overhead ein Programm dafür leicht erweitern und pflegen kann.

Ganz davon abgesehen habe ich schon das ein oder andere Mal erlebt wie der "Overhead" im Endeffekt zu einer höheren Leistung führt. Oder zumindest der Flaschenhals an einer ganz anderen Stelle liegt.

cu André

[pumuckl]

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Das sind nur ein paar Takte. Und da man solche switches ja nach möglichkeit nur selten durchläuft tut das nicht wirklich weh.

[hustbaer]

Arrays von Funktionszeigern bzw. Arrays von Zeigern auf Objekte mit virtuellen Memberfunktionen können manchmal sogar schneller sein als switch-Orgien.

Hier einer Variante im Vergleich mit der anderen grundsätzlich "Overhead" zuzuschreiben, halte ich nichtmehr für gewagt, sondern für schlichtweg falsch.

[u_ser-l]

geschweifte Klammern in separaten Zeilen stören die Lesbarkeit, denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, also brauchen sie auch keine eigene Zeile. Semikolons spendiert man ja auch keine eigenen Zeilen.

[Dravere]

u_ser-l schrieb:

..., denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, ...

Ehm, doch. Sie sagen dem Leser ganz klar, dass hier ein neuer Block startet und wo er wieder endet. Das erkennen von solchen Blöcken ist extrem wichtig für das Verständnis. Was gehört wozu.

Und wie machst du eigentlich eine schliessende Klammer, wenn nicht auf einer eigenen Zeile?

Aber naja, wie so oft, sowas ist einfach subjektiv

Grüssli

[FLOTSCHI]

u_ser-l schrieb:

geschweifte Klammern in separaten Zeilen stören die Lesbarkeit, denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, also brauchen sie auch keine eigene Zeile. Semikolons spendiert man ja auch keine eigenen Zeilen.

Burschi, du hast auch garnicht kapiert.
Du kannst nicht für jeden Menschen sprechen.

Es ist eine Frage des Charakters, der Gewohnheit. Die Welt ist kompliziert.

Für mich gehört '{' und '}' in eine eigene Zeile, da es einen Block besser hervorhebt.

Hier stört mich, dass dem Funktionsrumpf direkt der Code folgt. Es ist eine gewisse Unübersichtlichkeit da (Ist jetzt wohl nicht das beste Beispiel).

int main() {
    cout << 1 << endl;
}

Hier sieht man den Block genauer. Es ist schöner, perfekter, einheitlicher. Jaja, ich sag doch, es hängt mit dem Charakter zusammen.

int main()
{
    cout << 1 << endl;
}

Also hört auf verdummt zu verallgemeinen, es nervt.

[_matze]

u_ser-l schrieb:

geschweifte Klammern in separaten Zeilen stören die Lesbarkeit, denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, also brauchen sie auch keine eigene Zeile. Semikolons spendiert man ja auch keine eigenen Zeilen.

Seh ich auch so (abgesehen von der schließenden Klammer natürlich). Das jeweilige Schlüsselwort markiert den Blockanfang für mich genausogut wie die Klammer. Ist alles eine Sache des subjektiven Empfindens (und wahrscheinlich der Gewöhnung). Ich kann diesen in die Länge gezogenen Quelltext mit öffnender Klammer in einer Extra-Zeile, den viele hier favorisieren, einfach schlechter lesen...

[u_ser-l]

Dravere schrieb:

Ehm, doch. Sie sagen dem Leser ganz klar, dass hier ein neuer Block startet und wo er wieder endet. Das erkennen von solchen Blöcken ist extrem wichtig für das Verständnis. Was gehört wozu.

Ja, schon - aber wo der Block beginnt und endet zeigt in (fast) jedem mir bekannten Programm die Einrückung an - die geschweifte Klammer ist für die optische Blöcke-Erkennung eher redundantes "syntaktisches Rauschen" (in python bspw. schreibt man sie gar nicht erst, Einrücken reicht). Aber jedem, wie's ihm gefällt.

[Xebov]

Dravere schrieb:

Sie sagen dem Leser ganz klar, dass hier ein neuer Block startet und wo er wieder endet. Das erkennen von solchen Blöcken ist extrem wichtig für das Verständnis.

Der Meinung bin ich auch, ich setze manchmal sogar sehr gern ne Klammer bei einzeligen ifs um die Übersichtlichkeit zu steigern.

[_matze]

Xebov schrieb:

ich setze manchmal sogar sehr gern ne Klammer bei einzeligen ifs um die Übersichtlichkeit zu steigern.

Manchmal? Das mach ich immer (nur eben nicht mit öffnender Klammer in einer eigenen Zeile ). Ich mag diese Ein-Zeilen-Dinger gar nicht...

[Dravere]

u_ser-l schrieb:

... die geschweifte Klammer ist für die optische Blöcke-Erkennung eher redundantes "syntaktisches Rauschen" ...

Optische Verbesserungen sind oft redundant. Wir könnten schliesslich auch alle Variablennamen auf einen Buchstaben verkürzen, alle Leerzeichen weglassen usw. usf.

u_ser-l schrieb:

Aber jedem, wie's ihm gefällt.

Genau. Nur begreife ich nicht, wieso du dann noch so eine Bemerkung hingesetzt hast, obwohl es schon lange nicht mehr wirklich um den Codestil ging, schon gar nicht nur um diesen speziellen Fall. Und vor allem frage ich mich, wieso du es so absolut hingeschrieben hast, als wenn alles andere einfach falsch ist. Sogar noch mit Argumenten versehen, obwohl es elend subjektiv ist und die Argumente daher auch nicht viel mehr nützen.

@Xebov,
Mache ich immer so. Sowas ist einfach ziemlich unklar:

if(xyz)
    blablabla();
bliblablub();

Vor allem allerdings, wenn man zum Teil Code kopiert und die Formatierungen
werden nicht korrekt mitgenommen, dann endet es noch in sowas:

if(xyz)
blablabla();
bliblablub();

Das "manchmal" würde mich allerdings noch mehr stören, weil dann die Formatierung nicht durchgezogen ist. Das ist meiner Meinung nach das Schlimmste, was man machen kann. Egal ob und wo jemand die geschweiften Klammern hinsetzt, hauptsache er zieht die Sache einheitlich durch.

Grüssli

[Nexus]

Dravere schrieb:

Das ist meiner Meinung nach das Schlimmste, was man machen kann. Egal ob und wo jemand die geschweiften Klammern hinsetzt, hauptsache er zieht die Sache einheitlich durch.

Das Problem entsteht dann vor allem bei solchen Dingen:

if (bla)
    if (blu)
        bli;
else
    blo;

Bei verschachtelten oder komplexeren "Einzel-Anweisungen" mache ich auch immer Klammern. Aber bei "einfachen" eher nicht (ist etwas subjektiv). Vielleicht bin ich da zu wenig konsequent und du solltest mich jetzt ganz schlimm finden.

[5cript]

Ich sagte ja das sei grauenvoll, aber das hat den Vorteil, dass wenn man das ausdrucken will, dass alles in reihe und logisch aufgebaut ist. sonst macht word oder die txt ein zeilenumbruch und das ist dann wirklich GRAUENVOLL.

[_matze]

Tim06TR schrieb:

Ich sagte ja das sei grauenvoll, aber das hat den Vorteil, dass wenn man das ausdrucken will, dass alles in reihe und logisch aufgebaut ist. sonst macht word oder die txt ein zeilenumbruch und das ist dann wirklich GRAUENVOLL.

Seine Notation von Word anhängig zu machen, finde ich hingegen grauenvoll.