Diskussion:C++-Programmierung: Projektdefinition Archiv:Einheitlicher Code

Einheitlicher Code

Bisher sieht der Quellcode ungefähr so aus:

#include <iostream>

using namespace std;

int main()
{
  int i=6, j=7;
  const double n=2.1, *const m=&n;

  if (i < j)
    cout << "i ist kleiner als j";
  else
    cout << "i ist größer oder gleich j;";

  for (int k=19; k < 25; k++)
    cout << m << ": " << n << endl;

  return 0;
}

Ich würde schreiben:

#include <iostream>

using namespace std;

int main(){
    int i(6), j(7);
    double const n(2.1), *const m(&n);

    if(i < j)
        cout << "i ist kleiner als j";
    else
        cout << "i ist größer oder gleich j;";

    for(int k(19); k < 25; ++k)
        cout << m << ": " << n << endl;

    return 0;
}

Unterschiede:

• Eine geringere Einrückung als 4 ist in C++ schlichter Blödsinn. (Eine größere würde hier erstens zu viel Platz wegnehmen und erhöht zweitens die Übersicht nur gering bis gar nicht.)

Öhm, warum ist eine Einrückung von weniger als 4 Blösdinn? (Ernstgemeinte Frage; mich interessiert, wie Du gerade auf 4 kommst). Aber abgesehen davon, ich finde eine geringere Einrückung auch nicht so schlimm, die Zweier-Einrückung im ersten Beispiel finde ich sogar einen Tick leserlicher als die vierer, aber ich kann mich auch mit 4 anfreunden. Bei wesentlich mehr als 4 leidet meiner Meinung nach eher die Leserlichkeit, weil man mit den Augen weit hin und her springen muss. Funkysapien 05:21, 14. Jan. 2007 (CET)

Bei mehr als 4 geb ich dir recht! 3 oder gar 1 sind unüblich... Als ich mit programmieren anfing benutze ich Delphi (Objekt Pascal), damals empfand ich eine Einrückung von 4 als elende Platzverschwendung. In C++ hat man aber viel weniger zu schreiben und bei vielen Einrückungen kann das Auge schon bei ein paar Zeilen Unterschied (bei mir gilt das sogar für beide), nicht mehr auf den ersten Blick erkennen ob die Einrückung nun gleich ist oder nicht. Bei einfachen Beispielen mag 2 noch Sinn machen, bei komplexeren beispielen empfinde ich persönlich es als problematisch. --Prog 13:58, 14. Jan. 2007 (CET)

Hm, stimmt, bei zu wenigen kann man wirklich durcheinander kommen. Also, nehmen wir 4. Funkysapien 18:07, 14. Jan. 2007 (CET)

• Die öffnende geschweifte Klammer nimmt auf einer eigenen Zeile nur unnötig Platz Weg ohne die Übersicht deutlich zu erhöhen, den Zweck erledigt die Einrückung. Bei der schließenden Verhält sich das wieder anders, sie sollte auf den ersten Blick auffindbar sein, um die Einrückung auf Richtigkeit zu Prüfen.

Hm, ich finde wir sollten von unerfahrenen Lesern ausgehen, die noch lernen. Und dann finde ich, daß die öffnende Klammer in der gleichen Einrückung auf einer eigenen Zeile schon eher Sinn macht, um Anfang und Ende zu erkennen. Andererseits erkennt man die Zugehörigkeit vielleicht besser, wenn man so wie in deinem Beispiel schreibt. hmmm... unentschlossen. Egal wie, man müßte den Leser irgendwo explizit darauf hinweisen. Funkysapien 05:21, 14. Jan. 2007 (CET)

Wir schreiben einen Hinweis und benutzen erst mal die Variante, die ich Vorgeschlagen habe. Sie hat nämlich noch einen weiteren Vorteil: Wenn man das Buch ausdrucken will, passt mehr Code auf eine Zeile. --Prog 13:58, 14. Jan. 2007 (CET)

ok Funkysapien 18:07, 14. Jan. 2007 (CET)

Also ich finde, dass es der Übersicht erheblich hilft, wenn die einzelnen Blöcke klar erkennbar sind. Die "Leerzeile" in der die geöffnete geschweifte klammer steht hilft mir da enorm. Außerdem kenne ich es so aus den meisten Büchern. --Enaut 11:49, 26. Mär. 2007 (CEST)

Ich finde auch, dass man die geschweifte Klammer in eine eigene Zeile schreiben sollte. Enaut hat ja schon gute Argumente genannt.

--etlam 15:37, 22. Aug. 2007 (CEST)

• hinter if, for und Co setze ich kein Leerzeichen (ist nicht so wichtig)

Find ich gut, dadurch kommt die Zusammengehörigkeit von Klammer und Schlüsselwort davor besser raus. Funkysapien 05:21, 14. Jan. 2007 (CET)

Dann ist das beschlossen, es denn jemand findet noch ein wirklich gutes Gegenargument! --Prog 13:58, 14. Jan. 2007 (CET)

Jup, ich schließe mich meinem Vorredner an. Funkysapien 18:07, 14. Jan. 2007 (CET)

• ++k statt k++, die Postfix-Version verwende ich nur wenn es unbedingt nötig ist. Hier würde der Compiler den Unterschied wahrscheinlich beseitigen, aber wenn k ein Objekt einer Klasse gewesen währe hätte er das nicht getan. Wenn man sich von vorn herein an diese Schreibweise gewöhnt, hat man bei der Arbeit mit Objekten keine Probleme die schnelle Variante instinktiv zu wählen, denn die Postfix-Version ist nur selten wirklich nötig. (Das halte ich für wichtig!)

Ist der Präinkrementoperator inhärent schneller? Man lernt nie aus :) Funkysapien 05:21, 14. Jan. 2007 (CET)

Bei Postfix wird ein Temporäres Objekt erzeugt und zurückgegeben, weil ja der alte Wert zurückgegeben wird. In der Präfix Variante wird hingegen einfach eine Referenz auf sich selbst zurückgegeben. Beweis: ++++++++++i; geht, i++++++++++; geht nicht! (C++ ist Himmel und Hölle zugleich..., es gibt keine schönere Sprache, aber auch keine die mir mehr Kopfzerbrechen bereitet.) --Prog 13:58, 14. Jan. 2007 (CET)

Wem sagst Du das. Es gibt wirklich viele Stolpersteine, die in C++ verbaut sind. Das könnte sogar ein eigenes Kapitel werden, "Stolpersteine", irgendwo so gegen Ende des Buches, um unsere Leser genau darauf aufmerksam zu machen. Funkysapien 18:07, 14. Jan. 2007 (CET)

Oder gegen Anfang. Am Ende sollen vor allem erfahrene Programmierer angesprochen werden. Das Kapitel „Stolpersteine“ sollte am besten in einem sozusagen unabhängigem Teil stehen, da es die ja von einfachen Strukturen bis zum Komplexeste hin gibt. Am besten wir fügen auch einen Hinweis ein, dass gefundene hier (auf einer eigenen Seite) gern abgegeben werden dürfen. --Prog 19:27, 14. Jan. 2007 (CET)

• const schreibe ich grundsätzlich rechts neben das, zu dem es gehört. So verliert man die Übersicht bei komplexeren Ausdrücken nicht. Links daneben ist ja nur eine Ausnahme, falls links neben const nicht mehr steht. (Das ist ungewöhnlich aber nützlich!) --Prog 13:58, 14. Jan. 2007 (CET)

Hm, hab ich noch nie so gesehen. Aber stimmt, dann steht das Wichtigste immer an der ganz linken Position, das hilft dem Unerfahrenen bei der gedanklichen Priorisierung der Schlüsselwörter. Macht Sinn. Funkysapien 05:21, 14. Jan. 2007 (CET)

Dann müssen wir unbedingt einen Hinweis schreiben wie das Zustande kommt, denn es ist wirklich unüblich. --Prog 13:58, 14. Jan. 2007 (CET)

Ich finde, wir sollten überhaupt einen Abschnitt machen, in dem wir erläutern, daß C++ Vertauschung von manchen Schlüsselwörtern, Leerzeichen vor und in Klammern etc. toleriert, und wo das keinen Unterschied macht. Ich kann mich erinnern mir am Anfang meines Programmiererdaseins über soetwas sehr oft den Kopf zerbrochen zu haben, weil es eben die meisten Bücher garnicht erwähnen. Ich war am Freitag bei einem Einführungsvortrag über die Programmierung von Mikrokontrollern in Basic, und ein anderer Zuhörer hat gefragt, warum denn in dem Programmlisting überall eine Leerzeile drin ist, nur an einer Stelle zwei Leerzeilen und ob das einen Unterschied machen würde. Wir erfahrenen Programmierer nehmen das garnicht mehr wahr, aber ein Anfänger weiß nicht, ob das eine Bedeutung hat oder nicht, also sollten wir es ihm erklären.

Die Idee finde ich super. Was const angeht, das schreiben wir also auf die rechte Seite. --Prog 19:27, 14. Jan. 2007 (CET)

• Initialisierungen stehen bei mir ebenfalls grundsätzlich in Klammern, um sie nicht mit einer Zuweisung durcheinander zu bringen (Das ist noch ungewöhnlicher aber gleichfalls nützlich!)

Find ich Geschmachssache. Ok, du erzeugst keine anonymen temporären Instanzen wie mit i = 1, aber dafür ist die Bedeutung nicht so offensichtlich. Das könnte eventuell Verwirrung stiften. Funkysapien 05:21, 14. Jan. 2007 (CET)

Das ist so ziemlich die verquerste meiner Angewohnheiten. Temporäre Objekte erzeugt der Compiler hier nicht, er nimmt statt der Zuweisung einfache eine Initialisierung (Konstruktoraufruf) vor und genau diese Verwirrung möchte ich vermeiden. Dagegen spricht aber das ich wahrscheinlich nahezu der einzige Mensch auf diesem schönen Planeten bin, der das so schreibt. Ich habe es jedenfalls noch nie irgendwo gesehen. --Prog 13:58, 14. Jan. 2007 (CET)

Naja, ein gewisser Scott Meyers enpfiehlt dieses Vorgehen in seinem Buch "Effektiv C++ programmieren" (ISBN 3 8273 1305 8) in Lektion 12 mit den Worten (Zitat:) (...) Initialisierung mit Hilfe der Initialisierungsliste ist immer legal, niemals ineffizienter (...) und häufig sogar effizienter [als eine initialisierung per Zuweisung]. Er bezieht sich dabei allerdings hauptsächlich auf komplexe Klassen. Du bist also nicht der einzige, der das so macht, aber ich bin echt der Meinung wir sollten Ini per Zuweisung machen, das ist einfacher zu verstehen, und die Ini per Liste bei der Vorstellung von Klassenkonstruktoren mit einbauen als "übrigens, das geht so auch bei einfachen Variablen, weil...".

Da hatte ich das ehemals her, stimmt! Habs grad nochmal nachgeschlagen, das war nicht nur eins der besten, sondern auch eins der lustigsten C++-Bücher die ich je gelesen habe. Nun, ich würde sagen wir einigen uns erst mal auf einen Kompromiss: Sobald Klassen ins Spiel kommen (z. B.: string) benutzen wir die Klammern, bei einfachen Variablen der (aus Gewohnheitsgründen) besseren Lesbarkeit wegen die Variante mit dem Zuweisungsoperator, das hat dann auch keine Geschwindigkeitseinbußen zu Folge. Einverstanden? --Prog 19:27, 14. Jan. 2007 (CET)

Ich benutze normalerweise die folgende Regel: Wenn der Initialisierer (logisch) den Wert angibt, den das Objekt hinterher haben soll, dann benutze ich "=", um diese Tatsache zu unterstreichen (also z.B.

int i = 3;
double d = 4; // mathematisch gilt 4 = 4.0
std::complex<double> c = 45; // 45 = 45.0 + 0.0*i

usw.). Wenn hingegen der Initialisierer nicht den endgültigen Wert angibt, dann benutze ich die Klammerversion (also z.B.

std::vector<int> v(4); // der Vektor hat nicht den Wert 4, sondern 4 Elemente
std::ofstream f("filename"); // der Stream ist nicht "filename", sondern liest eine Datei dieses Namens

usw.). Diese Unterscheidung wird auch vom C++-Standard unterstützt, der die "="-Variante nur bei Vorliegen einer impliziten Konvertierung erlaubt (die ja in der Regel nur bei Wertäquivalenz verwendet werden sollte). --85.179.217.8 00:03, 30. Mai 2007 (CEST)

Finde ich gut, ich würde sagen, an die Regel können wir uns halten. --Prog 21:53, 30. Mai 2007 (CEST)

Schreibt bitte welche Punkte ihr gut und welche unzumutbar findet. Im Falle von unzumutbar bitte mit Begründung! Ich schreibe das nicht weil ich meine Schreibweise unbedingt durchdrücken will, sondern um hier auch Gegenargumente stehen zu haben. --Prog 23:18, 12. Jan. 2007 (CET)