K&R sagen aber vor der oeffnenden geschweiften Klammer einer Funktion muss ein newline hin. K&R!
Ich finds trotzdem unleserlich. Überlastet das linke Auge und der Code ist schwerer zu fassen.
Java-Programmierer? Wenn man mehrere Parameter definiert und idealerweise die Definition bei Bedarf umbricht ist die Klammer in der nächsten Zeile weit leserlicher:
Java-Stil ohne Zeilenumbruch:
int myFunction(string parameter_mit_einem_ewig_langen_namen, IrgendEineKlasse nochn_parameter, void* foo, double bar, bool baz, void* foo2, double bar2, bool baz2){
return 0;
}K&R/C-Stil ohne Zeilenumbruch:
int myFunction(string parameter_mit_einem_ewig_langen_namen, IrgendEineKlasse nochn_parameter, void* foo, double bar, bool baz, void* foo2, double bar2, bool baz2)
{
return 0;
}Das ist beides hässlich.
[line]
Java-Stil mit Zeilenumbrüchen:
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter, void* foo, double bar,
bool baz, void* foo2, double bar2, bool baz2){
return 0;
}K&R/C-Stil mit Zeilenumbrüchen:
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter, void* foo, double bar,
bool baz, void* foo2, double bar2, bool baz2)
{
return 0;
}Hier wird glaub ich gut deutlich, warum die Klammer in der nächsten Zeile sinnvoll ist.
Das passiert, wenn man Einrückung (indentation) und Ausrichtung (alignment) durcheinander würfelt. :finger:
Die Folgezeilen der Funktionssignatur will man je nach Geschmack und Situation entweder mit Leerzeichen so weit ausrichten, dass sie bündig zur öffnenden runden Klammer der Parameterliste sind:
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter, void* foo, double bar,
bool baz, void* foo2, double bar2, bool baz2) {
return 0;
} Oder man will sie alternativ mit (n = 2 * Einrückungsbreite) Leerzeichen ausrichten:
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter, void* foo, double bar,
bool baz, void* foo2, double bar2, bool baz2) {
return 0;
} [size=6]Außerdem gehört vor öffnende geschweifte Klammern am Zeilenende immer ein Leerzeichen. ;-)[/size]
8 „Gefällt mir“
Das ist wohl Geschmackssache. Finde – sowohl in der (schlechten) langen Zeile als auch bei den umgebrochenen* – die obere Lösung (Java-Stil) wesentlich angenehmer zu lesen.
(*wenn man denn wie Airhardt richtig einrückt 
)
Ausserdem ist das auch Quark, man will Parameter, wenn schon mehrzeilig, dann einen pro Zeile:
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter,
void* foo,
double bar,
bool baz,
void* foo2,
double bar2,
bool baz2)
{
return 0;
} Falls man dabei wahnsinnig wird ist das ein gutes Zeichen fuer eine Funktion mit ein paar zuvielen wirren Parametern.
Edit: ja, und eigentlich sollte das an der oeffnenden runden Klammer ausgerichtet sein, aber irgendwie mag mich das Forum nicht so ganz oder ich bin zu doof.
1 „Gefällt mir“
Dann aber bitte nur mit Leerzeichen an der runden Klammer ausgerichtet:
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter,
void* foo,
double bar,
bool baz,
void* foo2,
double bar2,
bool baz2)
{
return 0;
} Oder eben wenn die einen mit Tabs einrücken und die anderen mit Leerzeichen:
- Programmierer 1: 2 Tabs
- Programmierer 2: 8 Leerzeichen
- Programmierer 3: hat z.B. Tabs mit 2 Zeichen eingestellt. Und schon schaut das so aus:
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter, void* foo, double bar, // hier hat Programmierer 2 ausgerichtet
bool baz, void* foo2, double bar2, bool baz2) // hier Progammierer 1
{
return 0;
} Darum: geschweifte Klammer in die nächste Zeile.
int myFunction(string parameter_mit_einem_ewig_langen_namen,
IrgendEineKlasse nochn_parameter, void* foo, double bar,
bool baz, void* foo2, double bar2, bool baz2)
{
return 0;
} Das ist mein Stil, wenn sich VIM ums Ausrichten kümmert. Sobald ich das erste mal die Übersicht verliere richte ich die Parameter wie oben aus.
Ja, exakt genau deswegen macht man Einrueckung immer mit Tabs und Ausrichtung
immer mit Leerzeichen. Denn dann ist es vollkommen egal was jemand als
Anzeigebreite fuer einen Tab einstellt, der Code sieht immer richtig aus:
Tabbreite 8:
void foobar(int a,⏎
••••••••••••int b)⏎
{⏎
→if (bedingung1()⏎
→••••&& bedingung2()) {⏎
→ →blubber();⏎
→}⏎
}⏎
⏎
⏎
Tabbreite 3:
⏎
void foobar(int a,⏎
••••••••••••int b)⏎
{⏎
→if (bedingung1()⏎
→••••&& bedingung2()) {⏎
→ →blubber();⏎
→}⏎
}⏎
⏎
Tabbreite 27:
⏎
void foobar(int a,⏎
••••••••••••int b)⏎
{⏎
→if (bedingung1()⏎
→••••&& bedingung2()) {⏎
→ →blubber();⏎
→}⏎
}⏎
⏎
(→ ist ein Tab (Zeichen am Ende), • ein Leerzeichen, etc.)
Edit: gnagna, gewisse Unicode-Magie hat nicht funktioniert, Leerzeichen sind jetzt ordinaere Punkte…
5 „Gefällt mir“
Das ist vollkommen richtig. Ich hab meine [m]vimrc[/m] schon gestern wieder umgestellt 
Ich nutz gerade eh kein Python.
Ein Grund für \n{ ist mir noch eingefallen:
void myFunction()
#ifdef __APPLE__
{
//Apple-Code
}
#elif defined __MINGW32__
{
//Windows-Code
}
#elif defined __linux__
{
//Linux-Code
}
#endifist mMn leserlicher als:
void myFunction(){
#ifdef __APPLE__
//Apple-Code
#elif defined __MINGW32__
//Windows-Code
#elif defined __linux__
//Linux-Code
#endif
}weil damit klar wird, dass der komplette Rumpf anders ist.
Wir merken übrigens gerade ganz gut, warum es nicht nur eine Coding-Guideline gibt 
Nein, ganz im Gegentum. Wir merken, warum Leute gelegentlich der Illusion unterliegen eine schreiben zu muessen, wenns doch eigentlich mit genug nachdenken vollkommen klar ist, dass die einzig wahre Coding Guideline meine ist.
4 „Gefällt mir“
Ich hatte bei dem Thread-Titel nicht mit einer so sachlichen und interessanten Diskussion gerechnet. Da kann man ja echt noch was lernen. 
1 „Gefällt mir“
Meine Meinung als Coding Guideline Profi:
- Tabs komplett verbieten. Den Unterschied zwischen Einrückung und Ausrückung versteht niemand der sich an Coding Guidelines halten muss. Wenn er die geistige Kapazität dazu hätte, dann hätte er wohl was anderes gelernt.
- { kommt natürlich immer in eine neue Zeile. Es sei denn es ist Java, dann ist sowieso alles egal.
XD
!!!
1 „Gefällt mir“
Ich bin ja ein großer Freund von dieser Kompromisslösung:
function awesome()
{
if (foo) {
bar;
}
}- Die leere Zeile zwischen Methodenkopf und -rumpf hilft der Übersichtlichkeit
- Innerhalb des Codes ist es der gegenteilige Effekt (der Code würde durch \n{ unnötig zerkluftet)
Zur Einrückung mittels Tab und der damit verbundenen freien Breitenwahl muss ich einschränkend anmerken, dass man dann Probleme mit der maximalen Zeilenlänge bekommt (bei 8er Tabs sind 80 Zeichen deutlich schnell erreicht als bei 4ern). Daher muss man sich dort effektiv auch einig werden.
Dennoch halte ich Einrückung mittels Leerzeichen statt Tabs für ziemlich hirnverbrannt.
Das geht sogar noch und kann durchaus sinnvoll sein. Da wir uns gerade so liebevoll in Kleinigkeiten verlieren.: Klammern innerhalb von Funktionen lasse ich wann immer möglich weg, weil
Dafür nehme ich dann mutwillig in Kauf, dass ein difflog unter Umständen zwei sinnlose ± enthält, falls doch noch eine Zeile dazukommt. Aber das passiert eher selten.
Leerzeichen vor einer öffnenden geschweiften Klammer oder nach schließenden Runden brauch ich nicht unbedingt weil auch unnötige Spaces die zu überblickende Code-Fläche aufblähen .
Das sind aber eher persönliche Präferenzen, die je nach Projekt und Beteiligten nicht in Stein gemeißelt sind.
Maximale Zeilenlaenge ist ein Lochkartenproblem. 2016 noch irgendwas mit Lochkartenproblemen zu begruenden ist aeusserst rueckstaendig.
Generell sind lange Zeilen imho keinerlei Problem, jeder sinnvolle Editor kann geeignet umbrechen um die lesen zu koennen.
Allerdings sind lange Zeilen oft ein Anzeichen, dass man vielleicht doch mit ein paar \n zwischendrin den Code schoener strukturieren koennte, dann aber nicht um ein beliebiges Zeilenlaengenlimit zu vermeiden sondern wegen der Struktur.
Beispiel:
if ((foo + bar > 3) && (bla > 9) && (sonstwas() || fooo())) ...
if ((foo + bar > 3)
&& (bla > 9)
&& (sonstwas()
|| fooo())) ...(gut, leicht uebertrieben…)
Jeder sinnvolle Editor kann auch die Einrueckung dem persoenlichen Geschmack anpassen. Wenn man natuerlich vom Steuerzahler bezahlt wird, hat man offensichtlich genug Zeit, sich Gedanken ueber allenfalls akademische Probleme zu machen.
Im uebrigen schliesse ich mich der Meinung von cody an. IMHO der einzig sinnvolle Beitrag in diesem Thread.
Das ist etwa die Stellenbeschreibung, ja.
10 „Gefällt mir“
Nein, nur unter gewissen Einschraenkungen. Wenn ich die Tabbreite einstellen kann muss auch jemand mal Tabs benutzt haben. Wenns Leerzeichen sind hab ich verloren. Nochmal ‚indent -i8 -kr‘ oder sowas drueberlassen hilft auch nix, weil ich ja meistens was aendern will, dann committen muss, dann gibts aber ein nutzloses Riesen-Diff wegen des indent-Durchlaufs.