Wie setzt ihr Klammern?

1.

Kevin schrieb:
> Ach so, na dann,
>
> If (x)
>  {
>    Krach, Schepper, Bumm;
>   )

Ich denke, syntaktisch korrekt sollte es auch sein.

Ingo schrieb:
> Wie setzt ihr eure Klammern bzw. Welche Schreibweise gestaltet sich bei
> viel Code eurer Meinung übersichtlicher?

Weder noch. Ich machs so:

1

if(x) {

2

  Bla;

3

  Blabla;

4

  }

5

else {

6

  Blubber;

7

  Blub;

8

  }

Ist aber echt Geschmacksache. Mein Bildschirm hat eben nicht so arg 
viele Zeilen, da ist kompakter Code übersichtlicher, weil ich dann nicht 
so viel scrollen muss.

Markus W. schrieb:
> Weder noch. Ich machs so:
> if(x) {
>   Bla;
>   Blabla;
>   }
> then {
>   Blubber;
>   Blub;
>   }

War nicht von C die Rede?

Ein "besser" gibt es hier natürlich nicht. Die Hauptsache ist hier wohl 
eher die Konsequenz, gerade wenn man im Team arbeitet. Das erleichtet 
vor allem das Lesen von "fremden" Quellcode (und darunter verstehe ich 
z.B. auch eingenen Quellcode, der etwas "älter" ist). I.d.R. sind das 
aber Fragen, welche im Rahmen von Code Conventions 
(https://de.wikipedia.org/wiki/Code_Convention) geklärt werden und 
gerade bei größeren Projekten verpflichtend sind.

Sinnvoll kann es unter Umständen sein die Code Conventions von "großen" 
Projekten zu übernehmen. Im Bereich "C" gibt es da unter anderem z.B. 
die GNU Coding Standards 
(https://www.gnu.org/prep/standards/standards.html) oder den Linux 
kernel coding style 
(https://www.kernel.org/doc/Documentation/CodingStyle).

Ingo schrieb:
> Interessant wie viele Sachen sich unterscheiden. Jemand dabei der das
> Hauptberuflich macht und am Tag zig Zeilen Code schreibt?

Ja, ich - wie vermutlich die anderen auch. Allerdings verwende ich für 
Mikrocontroller viel lieber Assembler.

Ansonsten stimme ich Karol Babioch voll und ganz zu.

Karol Babioch schrieb:
> Ein "besser" gibt es hier natürlich nicht. Die Hauptsache ist hier wohl
> eher die Konsequenz, gerade wenn man im Team arbeitet. Das erleichtet
> vor allem das Lesen von "fremden" Quellcode (und darunter verstehe ich
> z.B. auch eingenen Quellcode, der etwas "älter" ist). I.d.R. sind das
> aber Fragen, welche im Rahmen von Code Conventions
> (https://de.wikipedia.org/wiki/Code_Convention) geklärt werden und
> gerade bei größeren Projekten verpflichtend sind.

genau.

Ich arbeite an verschiedenen Projekten, die jeweils einen anderen 
Codingstyle haben. Sobald man den jeweiligen Codingstyle verinnerlicht 
hat, geht das umstellen auch einfacher und schneller.

Wichtig ist vor allem Konsistenz innerhalb eines Projektes.

Anfangs habe ich es so gemacht:
> If (x){
>    Bla bla;
> }

In der Schule haben wir es dann so "gelernt":
> If (x)
> {
>    Bla bla;
> }

mittlerweile gefällt mir die zweite Methode viel besser als die erste, 
ich finde es einfach übersichtlicher...

HildeK schrieb:
> Ingo schrieb:
>> If(x)
>> {
>>    Bla bla;
>> }
>
> ist für mich übersichtlicher.

Für mich auch:

Die schliessende Klammer auf der gleichen Ebene wie die öffnende.

Und vor die ( gehört ein Leerzeichen:

1

if (x)

2

{

3

    Bla bla;

4

}

5

else if (y)

6

{

7

    blubb (x);

8

}

In diesem Fall setze ich überhaupt keine Klammern:

1

if(x)

2

  Bla bla;

Außerdem schreibe ich das "if" immer mit einem kleinen 'i', auch am
Zeilenanfang :)

Wenn die Einrückungen überall richtig gemacht werden, spielt die
Position der Klammern für mich persönlich kaum keine Rolle. Auch so
etwas würde ich nicht anprangern:

1

if(x>5) {

2

  a = 0;

3

  b = 1; }

4

else {

5

  a = 2;

6

  b = 3; }

Immerhin spart man dadurch einige Fast-Leerzeilen, bekommt dadurch mehr
Code auf einer Bildschirmseite zu sehen und hat deswegen einen besseren
Überblick.

Nachteil: Das Einfügen neuer Zeilen am Ende eines Blocks ist etwas
umständlich, weil man dann die letzte Zeile vor der schließenden Klammer
umbrechen muss.

Deswegen ist folgendes ein guter Kompromiss, den ich auch verwende, wenn
nicht gerade irgendwelche Style-Guides etwas anderes vorschreiben:

1

if(x>5) {

2

  a = 0;

3

  b = 1;

4

}

5

else {

6

  a = 2;

7

  b = 3;

8

}

Eigentlich wurde schon alles gesagt: Code conventions bei 
größeren/Team-Projekten etc.
Wenn ich's aussuchen darf bzw. intern:
Beispiel 1. das allerdings an allen Stellen (d.h. auch bei struct, 
class, Funktionen etc.) und TAB = 4 Leerzeichen
Wenn die Sprache auch ausgesucht werden darf:

1

if abc then

2

   xyz

3

elif bcd 

4

   yza 

5

else

6

   zab

Ctrl+E, D

Mal etwas avantgardistisch:

1

if(x>5)                                                                {

2

  a = 0                                                               ;

3

  b = 1                                                               ;}

4

else                                                                   {

5

  a = 2                                                               ;

6

  b = 3                                                               ;}

7

funktion(a, b)                                                        ;

Alle hässlichen Semikola und geschweiften Klammern werden dorthin ver-
bannt, wo sie das Auge kaum noch stören, vom Compiler aber noch gesehen
werden. Wenn man jetzt nur noch die wenig Information enthaltenden run-
den Klammern in der If-Anweisung und dem Funktionasaufruf ins Abseits
stellen könnte, würde der C-Code schon beinahe so edel aussehen wie der
Nicht-C-Code von meinem Vorvorposter ;-)

Wiggerl schrieb:
> Heute weiß ich, dass mein Monitor groß genug ist um die Nachteile des
> Allman-Stil zu kompensieren

Vorsicht: Die vertikale Auflösung (vor allem bei Laptopdisplays) ist
derzeit rückläufig. In ein paar Jahren, wenn die Standardauflösung
3840×540 (Superwide Full HD) oder gar 7680×270 (Ultrawide Full HD) sein
wird, wirst du dich wieder an die Vorteile des K&R-Stils erinnern ;-)

Yalu X. schrieb:
> Mal etwas avantgardistisch:

Sieht wirklich sehr schön aus, Kann man Eclipse beibringen das 
automatisch so zu machen? :-D

Yalu X. schrieb:
> Vorsicht: Die vertikale Auflösung ist (vor allem bei Laptopdisplays)
> derzeit rückläufig. In ein paar Jahren, wenn die Standardauflösung
> 3840×540 (Superwide Full HD) oder gar 7680×270 (Ultrawide Full HD) sein
> wird, wirst du dich wieder an die Vorteile des K&R-Stils erinnern ;-)

Echt traurig, dass da sogar einen Funken Wahrheit drin steckt...

jogitech schrieb:

> if(...)
>     {
>     x = blabla
>     }
>
> spricht da etwas dagegen?

Es ist sehr unüblich.  Das ist an sich nix schlimmes, erschwert dir aber 
gerne das Lesen von Fremdcode:  Code (bzw. alles was man liest) wird 
eher als Bild wahrgenommen als die Abfolge einzelner Zeichen.

Wie leicht man einen Text liest, wird daher auch dadurch bestimmt, wie 
vertraut ein bestimmer Testsatz bz. Coding-Rule ist.  Unübliche 
Coding-Rules erschweren also das Lesen von Code — sowohl wenn du anderen 
Code liest, als auch wenn andere deinen Code lesen.

Ausserdem ist es schwer, sich solche hausbackenen Stile wieder 
abzugewöhnen. Das weiß ich aus eigener Erfahrung ;-)

Die Klammer hinten ans Zeilenende des if zu schreiben oder mit dem Code 
einzurücken hat aber auch handfeste Nachteile in ausgewachsenen 
Projekten mit komplexen Klauseln.

Ein Beispiel für so ein Projekt, in den lange Klauseln keine Seltenheit 
sind, ist GCC.  Hier zwei Beispiele aus avr-gcc, bei denen das 
Verhältnisse zwischen Codegröße in der Klausen und Codegröße im Block 
genau umgekehrt sind wie gewohnt:

Beispiel 1
 

1

  if (EQ != GET_CODE (XEXP (ifelse1, 0))

2

      || !REG_P (XEXP (comp1, 0))

3

      || !CONST_INT_P (XEXP (comp1, 1))

4

      || XEXP (ifelse1, 2) != pc_rtx

5

      || XEXP (ifelse2, 2) != pc_rtx

6

      || LABEL_REF != GET_CODE (XEXP (ifelse1, 1))

7

      || LABEL_REF != GET_CODE (XEXP (ifelse2, 1))

8

      || !COMPARISON_P (XEXP (ifelse2, 0))

9

      || cc0_rtx != XEXP (XEXP (ifelse1, 0), 0)

10

      || cc0_rtx != XEXP (XEXP (ifelse2, 0), 0)

11

      || const0_rtx != XEXP (XEXP (ifelse1, 0), 1)

12

      || const0_rtx != XEXP (XEXP (ifelse2, 0), 1))

13

    {

14

      return false;

15

    }

Beispiel 2
 

1

  /* Ensure that caller and callee have compatible epilogues.  */

2

3

  if (cfun->machine->is_interrupt

4

      || cfun->machine->is_signal

5

      || cfun->machine->is_naked

6

      || avr_naked_function_p (decl_callee)

7

      /* FIXME: For OS_task and OS_main, we are over-conservative.

8

         This is due to missing documentation of these attributes

9

         and what they actually should do and should not do.  */

10

      || (avr_OS_task_function_p (decl_callee)

11

          != cfun->machine->is_OS_task)

12

      || (avr_OS_main_function_p (decl_callee)

13

          != cfun->machine->is_OS_main))

14

    {

15

      return false;

16

    }

17

18

  return true;

Hier sind Einrückungen, Zeilenumbrüche und Leerzeichen übrigens gemäß 
den für GCC verbindlichen GNU-Rules.

Yalu X. schrieb:
> Mal etwas avantgardistisch:

Sehr schön

> Alle hässlichen Semikola und geschweiften Klammern werden dorthin ver-
> bannt, wo sie das Auge kaum noch stören, vom Compiler aber noch gesehen
> werden. Wenn man jetzt nur noch die wenig Information enthaltenden run-
> den Klammern in der If-Anweisung und dem Funktionasaufruf ins Abseits
> stellen könnte, würde der C-Code schon beinahe so edel aussehen wie der
> Nicht-C-Code von meinem Vorvorposter ;-)

F#, ML, Haskell

Wenn nur die Semikola stören, aber geschweifte Klammern vorkommen 
sollen: Go
Sollen zumindest die runden Klammern beim if erhalten bleiben: Scala, 
wer mehr Klammern braucht -> http://xkcd.com/297/

Urban B. schrieb:
> Sieht wirklich sehr schön aus, Kann man Eclipse beibringen das
> automatisch so zu machen? :-D

Zumindest NetBeans kann man unter Fonts&Colors beibringen die 
"überflüssigen" Trennzeichen weiß auf weiß darzustellen, dann sind alle 
({,;}) weg ;-)

Verwirrter Anfänger schrieb:
>> if(x)
>>   Bla bla;
>>
>
> Nur als Anmerkung:
> Bei uns kriegt man da ganz schnell einen auf die Finger gehauen. Das
> kann spät abends zu dämlichen Fehlern führen:

Ich weiß. In einigen Programmierichtlinien sind deswegen die
geschweiften Klammern auch für Einzelanweisungen explizit
vorgeschrieben.

Noch besser ist es aber, spätabends gar nicht mehr zu programmieren,
sondern allenfalls in mikrocontroller.net darüber zu diskutieren ;-)



@alle Klammerhasser:

Es gibt da tatsächlich ein paar Verrückte, die C seiner geschweiften
Klammern und Semikola beraubt und stattdessen eine Python-ähnliche
Blocksyntax aufgesetzt haben:

  http://blog.brush.co.nz/2007/09/nobraces/
  http://code.google.com/p/pythoidc/

Natürlich gibt es das Ganze auch andersherum für Leute, die die
erzwungene Einrückung in Python hassen und stattdessen lieber ein paar
Klammern schreiben:

  http://timhatch.com/projects/pybraces/

Arc Net schrieb:
> F#, ML, Haskell

Das Schöne bei diesen Sprachen ist, dass man zwischen beiden Modi
aussuchen kann:

- Einrückungen syntaktisch relevant:
  -> einfachere Syntax
  -> mehr Übversichtlichkeit

- Einrückungen nicht relevant, Strukturierung erfolgt durch zusätzliche
  Schlüsselwörter und/oder Sonderzeichen:
  -> praktisch im interaktiven Modus und bei automatischer Code-
     Generierung
  -> die Tabulatorfritzen fallen nicht ständig auf die Nase ;-)


> Wenn nur die Semikola stören, aber geschweifte Klammern vorkommen
> sollen: Go
> Sollen zumindest die runden Klammern beim if erhalten bleiben: Scala,
> wer mehr Klammern braucht -> http://xkcd.com/297/

Eins hast du noch vergessen:

Wen alle Klammern, alle Satzzeichen, alle Operatorzeichen, alle
Buchstaben und alle Ziffern stören, der nehme Whitespace:

  http://de.wikipedia.org/wiki/Whitespace_%28Programmiersprache%29

;-)

Ich schreibe auch gerne etwas kompakter also Variante 1.

Wie haltet ihr es bei switch-case Blöcken?

1

switch(x) {

2

case 1:

3

    blah();

4

    break;

5

case 2:

6

    blah();

7

    break;

8

case 3:

9

    blah();

10

    break;

11

}

So schaut es bei mir aus. Ich mag es halt nicht wenn der Code so breit 
wird, dass man ständig den horizontalen Scrollbalken des Editors 
verwenden muss.

M. K. schrieb:
> Wie haltet ihr es bei switch-case Blöcken?

Da rücke ich 2-mal ein, einmal die Case und dann den Code.
D.h. unter dem 's'(witch) steht nur die schließende '}' und ich erkenne 
sofort das Ende.

Auch gönne ich mir eine Leerzeile vor jedem Case. Da sieht man besser, 
welche Case es gibt, bzw. ob einer fehlt.


Peter

Leerzeichen setze ich anders.
Die Schlüsselwörter kennt man ja, die braucht man nicht extra 
abzusetzen, das macht außerdem schon das Syntax-Highlighting.

Dagegen setze ich die Ausdrücke ab, denn auf die kommt es ja an. Die 
sollten also hervortreten und leicht lesbar sein:

1

  if(    Ausdruck1

2

      && Ausdruck2 ){

3

    blabla;

4

  }else{

5

    blubblub;

6

  }

Peter

Also ich bevorzuge auch eindeutig oben nr 2 , die Blockübersicht bleibt 
erhalten. für mich ist übersichtlichkeit wichtig.

1

switch(x) 

2

{

3

  case 1:

4

    blah();

5

  break;

6

  case 2:

7

    blah();

8

  break;

9

  case 3:

10

    blah();

11

  break;

12

}

aber case ist etwas besonderes der sieht auch schon mal so aus

1

switch(x) 

2

{

3

  case  1:  blah(x+7);                 y= 0;  break;

4

  case  2:  blah(x/6);    bla2(14+x);  y= 2;  break;

5

  case  3:  blah(y+8888); bla2(122);   y=-2;  break;

6

    ...

7

  case 23:  blah(x);      bla2(3);     y= 7;  break;

8

  default: err....

9

}

 sprich alles steht schon senkrecht untereinander, so das man die 
Unterschiede schön schnell erfassen kann. gibt aber nur für die Stellen
 die so aufgebaut sind. sprich passen in eine Zeile unterscheiden sich 
durch Feinheiten. ansonsten würde so ein switch über Seiten gehen.
 Auch gibts bei mir oft Einzeiler

1

 if ( x > 12 ) x=12; else if ( x <  0) x= 0;  // check überlauf x

2

 if ( y > 22 ) x=22; else if ( y <= 0) y=-1;  // check überlauf y

 Wenn man den Code lesen will, beschäftigt man sich einmal mit der 
Zeile, danach kann man sie mit dem Kommentar schnell erfassen. um den 
Ablauf zu erfassen ist es dann viel einfacher, weil man den zu 
verstehenene Block ohne zu scrollen lesen kann, sonst wären die beiden 
if ja schon nem netbook schon fast eine ganze Seite code. Anfänger sind 
mit solchen Zeilen vielleicht überfordert, aber ich kann sie problemlos 
mit einem Blick erfassen. Jeder erfahrene Programmierer sollte so eine 
Zeile problemlos erfassen und den Sinn verstehen können ohne ernsthaft 
dadrüber nachdenken zu müssen was sie macht.
  Darum mag ich auch z.b. keine Sprachen die mir eine Formatierung 
aufzwingen wollen und für jede Kleinigkeit eine eigene Zeile haben 
wollen. (Assembler sehe ich nicht als Sprache, darum fällt es auch nicht 
unter dieser Aussage, das ist etwas für sich.)

Marwin schrieb:
> Vieleicht wuerde es einigen helfen, sich mal mit den C-Grundlagen zu
> beschaeftigen. Dann wuessten sie, dass die Klammen zum Block gehoeren
> und nicht zum if, else, while oder sonstwas. Und was logisch zusammen
> gehoert, sollte auch optisch zusammen stehen. Also kommt die oeffnende
> Klammer an den Anfang des Blocks und nicht an's Ende vom if, else,
> while, etc...

"First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it.  Burn them, it's a great symbolic gesture." scnr
http://www.kernel.org/doc/Documentation/CodingStyle
K&R, Stroustrup http://www.stroustrup.com/bs_faq2.html

Marwin schrieb:
> Also kommt die oeffnende Klammer an den Anfang des Blocks und nicht
> an's Ende vom if, else, while, etc...

Also so:

1

if(x>5)

2

{a = 0;

3

 b = 1;}

4

else

5

{a = 2;

6

 b = 3;}

So sind die Klammern maximal dicht am Anfang und am Ende des jeweiligen
Blocks ;-)

So:

1

void Func(int foo)

2

{

3

  int x;

4

5

  if(foo) {

6

    switch(foo) {

7

      case A:

8

        x = 7;

9

        break;

10

11

      case B: {

12

        x = 42;

13

        Func2(x);

14

      } break;

15

    }

16

  }

17

  else {

18

    foo = 2;

19

  }

20

21

  if(x) {

22

    foo = 1;

23

  } else {

24

    foo = 2:

25

  }

26

27

  do {

28

   x++;

29

  } while(foo--);

30

}

Marwin schrieb:
> Und was logisch zusammen
> gehoert, sollte auch optisch zusammen stehen.

Genauso sehe ich das auch. Alles in den Klammern wird bedingt 
ausgeführt, gehört also zum if, while usw.. Daher ist es für mich 
vollkommen logisch, daß es auch direkt hinter dem if() beginnt.


Peter

Dazu kommen dann einige Variationen, z.B:

1

if(foo<7) x=2; else x = 1;

oder die zweite case/break Variante von Mikel.

Also speziell bei switch hab ich mir folgendes angewöhnt:

1

switch (x) {

2

  case (1): {

3

    blah();

4

  }break;

5

6

  case (2): {

7

    blubb();

8

  }//fallthrough

9

10

  default: {

11

    boing();

12

  }

13

}

die extra Klammern sind sicher nicht notwendig, ich finds aber 
konsistenter mit anderen Konstrukten und die anweisungsblöche werden 
schön von case und break umrahmt.

Random ... schrieb:
> if(foo<7) x=2; else x = 1;

1

x = foo < 7 ? 2 : 1;

Ingo L. schrieb:
> M. K. schrieb:
>> x = foo < 7 ? 2 : 1;
> Ja, sowas kann dann auch jeder nachvollziehen. Sowas schreibt glaube ich
> kaum einer.

Doch, eig. schon :-)

1

foo = x? 1 : 2;

2

3

#define NOZERO(x)      (x? x : 1)

4

5

led_out(1<<(ledCnt = ++ledCnt<8 ? ledCnt : 0));  // feed the running light

@M.K.:
Das war nur ein Beispiel :-)

M. K. schrieb:
> Random ... schrieb:
>> if(foo<7) x=2; else x = 1;
>
>

1

x = foo < 7 ? 2 : 1;

Ich würde bei soetwas klammern, es erhöht die Lesbarkeit.

>

1

x = (foo < 7) ? 2 : 1;

Ingo L. schrieb:
> Alexander v. Grafenstein schrieb:
>> switch (x) {
>>   case (1): {
>>     blah();
>>   }break;
>>
>>   ...
>> }
>
> Beim case (1) kommt das break aber vor die Klammer :)

Hatte ich zuerst, aber so gefällts mir besser. vgl. z.B. auch do{ 
}while;

Also ich schreib immer so:

1

if(x == true){

2

  //Code

3

  //bla bla bla

4

}

5

6

else{

7

  //anderer Code

8

}

9

10

if(x == true) einzeiler();

11

else anderer_einzeiler();

An der schließenden Klammer nach oben gepeilt findet man immer das 
dazugehörige if (oder else oder switch usw.).

Alles zusammengerückt, allerdings in der Bedingung dann ein Leerzeichen, 
wo es hinkommt (x == true).

Michael Skropski schrieb:

>
> An der schließenden Klammer nach oben gepeilt findet man immer das
> dazugehörige if (oder else oder switch usw.).

 Du findest zwar das if, aber ob das dazugehört entscheidet die öffnende 
Klammer, darum gehören bei mir das "i", "{" und "}" auf eine Line um 
auch beim Ausdruck ganz problemlos die Verschachtelung überprüfen zu 
können, da alles auf einer Geraden ist. Man muß für die Verschachtelung 
einfach nur den linken Rand senkrecht verfolgen.

Mikel M. schrieb:
> Ich würde bei soetwas klammern, es erhöht die Lesbarkeit.
>

1

x = (foo < 7) ? 2 : 1;

Ich schreibs so:

1

x= foo<7? 2: 1;

Jeder halt wie er mag. :-)

Das grenzt ja schon an religiöses Geseier ...

Geschweifte Klammern gehören immer auf eine eigene Zeile!

Warum das nur genau so richtig ist, werdet ihr merken wenn ihr
1. mal mit einer Versionsverwaltung gearbeitet habt.
2. bedingte Compilierung in nicht unerheblichem Umfang braucht.

Denn dann fliegt euch solcher Geiz-ist-geil-Code um die Ohren:

1

If (x){

2

   Bla bla;}

Grüße.

Michael L. schrieb:
> Denn dann fliegt euch solcher Geiz-ist-geil-Code um die Ohren:If (x){
>    Bla bla;}

Wenn Du schon damit Probleme hast ...

Joachim Drechsel schrieb:
> Wenn Du schon damit Probleme hast ...

Wo habe ich das geschrieben? Aber starte ruhig so eine Nebelkerze.
Lenkt ja prima davon ab, dass du nichts verstanden hast.

SCNR

Definitiv Nummer 1, weil ich unnötige Zeilen nicht mag, ich finde das 
einfach so übersichtlicher.

Michael L. schrieb:
> Joachim Drechsel schrieb:
>> Wenn Du schon damit Probleme hast ...
>
> Wo habe ich das geschrieben? Aber starte ruhig so eine Nebelkerze.
> Lenkt ja prima davon ab, dass du nichts verstanden hast.
>
> SCNR

Was ein Unsinn ...

Michael L. schrieb:
> Warum das nur genau so richtig ist, werdet ihr merken wenn ihr
> 1. mal mit einer Versionsverwaltung gearbeitet habt.

Wie kommst du darauf?

Bei mir hat sich die Versionsverwaltung noch nie über die Klammersetzung
beschwert, egal nach welchem Style-Guide ich programmiert habe. Selbst
Nicht-C-Programme, die überhaupt keine geschweiften Klammern verwenden
oder wo diese eine ganz andere Bedeutung haben, verdaut sie problemlos.

Klammeraffe schrieb:
> Pfeif auf C/C++/Java!
>
> Es lebe Brainf.u.c.k:
> http://de.wikipedia.org/wiki/Brainf.u.c.k
> (letzten 3 Punkte im Link entfernen, musste sein, da Beitrag sonst als
> "SPAM" abgelehnt wurde.
>
> Was waren das noch für Zeiten, als nicht jeder Spacko am Rechner
> rumfummeln durfte ...
>
> P.S. Überarbeitet mal eure Forensoftware. Brainf.u.c.k. ist einer
> ordentliche Programmiersprache.
> Dummsuff beim Absenden: "Der Beitrag scheint Spam zu enthalten:
> "f.u.c.k"

Wie alt bist du? 10?  Was bedeutet, was waren das für Zeiten? Brainf*** 
ist niemals eine urzeitliche Sprache gewesen, in der in älteren Tagen 
programmiert wurde. Da wären eher Maschinensprache, FORTRAN, BASIC und C 
(gibt noch andere Kandidaten, aber sicher nicht Brainf***).
Deine Aussage macht dich eher lächerlich.

Yalu X. schrieb:
> Michael L. schrieb:
>> Warum das nur genau so richtig ist, werdet ihr merken wenn ihr
>> 1. mal mit einer Versionsverwaltung gearbeitet habt.
>
> Wie kommst du darauf?
>
> Bei mir hat sich die Versionsverwaltung noch nie über die Klammersetzung
> beschwert, egal nach welchem Style-Guide ich programmiert habe. Selbst
> Nicht-C-Programme, die überhaupt keine geschweiften Klammern verwenden
> oder wo diese eine ganz andere Bedeutung haben, verdaut sie problemlos.

Nun ja, der Versionsverwaltung ist die Klammersetzung auch pupsegal.

Aber wenn du ein diff machst, dann werden die Unterschiede sehr schnell 
unübersichtlich, wenn, was gar nicht so selten der Fall ist, am Anfang 
oder Ende eines geklammerten Code-Blocks noch ein Statement eingefügt 
werden muss. Dann bekommst du statt einer simplen zusätzlichen Zeile 
eine Ersetzung einer Zeile auf der einen Seiter durch 2 Zeilen auf der 
anderen angezeigt. OK, bei 5-10 Zeichen pro Zeile wie im Beispiel ist 
das nicht sooo dramatisch. Aber wer mal einen umfangreicheren 
Code-Review/QS mit etwas mehr als 100 Codezeilen (also eher ab 10^6 bis 
10^7 Zeilen) machen darf/muss, wird es möglicherweise besser verstehen.

Mal abgesehen davon ist die Erkenntnis auch nicht von mir (-> Literatur, 
wurde auh schon verlinkt). Aber sie hat sich schon oft bestätigt.

Grüße.

docean schrieb:
>> Wie kommst du darauf?
>
> https://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#Horstmann

Michael L. schrieb:
> Aber wenn du ein diff machst, dann werden die Unterschiede sehr schnell
> unübersichtlich, wenn, was gar nicht so selten der Fall ist, am Anfang
> oder Ende eines geklammerten Code-Blocks noch ein Statement eingefügt
> werden muss.

Ok, das ist ein Argument. Wobei ein vernünftiges Diff-/Merge-Tool ja
nicht nur geänderte Zeilen anzeigt, sondern auch die Unterschiede
innerhalb von Zeilen. Damit wird sofort deutlich, dass sich die eine
Zeile nur deswegen geändert hat, weil die geschweifte Klammer in die
neu eingefügte Zeile gerutscht ist. Es kann also nicht die Rede davon
sein, dass einem der "Geiz-ist-geil-Code um die Ohren fliegt".

Es ist diesbezüglich auch nicht unbedingt erforderlich, jede geschweifte
Klammer in eine eigene Zeile zu schreiben. Sie sollte nur nicht zusammen
mit einer Anweisung des Blocks, die sie umschließt, in einer Zeile
stehen.

So etwas ist also nicht so toll (so machen's auch die wenigsten):

1

if(x > 5)

2

{ a = 0;     // <- nicht so toll

3

  b = 1; }   // <- dto.

4

else

5

{ a = 2;     // <- dto.

6

  b = 3; }   // <- dto.

Folgendes ist aber "VCS-fest", da nach Belieben neue Codezeilen
eingefügt werden können, ohne die Klammern zu verschieben:

1

if(x > 5) {

2

  a = 0;

3

  b = 1;

4

} else {

5

  a = 2;

6

  b = 3;

7

}

Michael L. schrieb:
> Yalu X. schrieb:
>> Michael L. schrieb:
>>> Warum das nur genau so richtig ist, werdet ihr merken wenn ihr
>>> 1. mal mit einer Versionsverwaltung gearbeitet habt.
>>
>> [...]
>>
>
> Nun ja, der Versionsverwaltung ist die Klammersetzung auch pupsegal.

Zitat Onkel Wiki:

>> Für VCS-Tools ist dieser Stil problematisch. Fügt man ein neues
>> Statement zwischen dem "{" und dem ersten Statement ein, erscheint
>> diese Änderung als "eine Zeile wird durch 2 Zeilen ersetzt" statt
>> "eine neue Zeile wurde eingefügt". Das heißt, die ursprüngliche Zeile
>> wird als "geändert" markiert, obwohl sie semantisch gleich geblieben ist.

Mikel M. schrieb:
> Du findest zwar das if, aber ob das dazugehört entscheidet die öffnende
> Klammer

1

int main(){

2

  if(...){

3

    while(...){

4

      if(...){

5

        //...

6

      }

7

    }

8

  }

9

  else{

10

    switch(...){

11

      case 1:

12

        //bla bla bla

13

        break;

14

      case default:

15

        //bla

16

        break;

17

    }

18

  }

19

}

Es ist aber für mich egal, ob ich weiß, dass hinter der Bedingung eine 
"{" ist oder dass ich sehe, das darunter eine "{" ist. Zu jeder if 
(usw.) gehört eine geschwungene Klammer, also muss diese Klammer nicht 
dadrunter sein, weil ich weiß, dass es sie gibt. Da wo man sie weglassen 
kann schreib ich den Rest in die gleiche Zeile. Aber jeder macht es halt 
so wie er will.

Marwin schrieb:
> Ich frage mich, ob ihr Buecher lesen wuerdet, die die Autoren nach euren
> Regeln geschrieben haben.

Wahrscheinlich nicht, weil sie so viel Whitespace enthielten, dass ein
200-seitigen Taschenbuch schnell zu einem 5-bändigen Werk mit 800 Seiten
pro Band explodieren würde. Das wäre mir einfach zu teuer.

> Keine Absaetze, keine Leerzeilen, ohne Punkt und Komma.

Wo vermisst du in den bisher geposteten (ernstgemeinten) Vorschlägen
diese Elemente? Wobei man ein 6-zeiliges Beispiel nicht unbedingt mit
der gleichen Anzahl an Leerzeilen spicken muss. Bei größeren Programmen
herrscht aber sicher Einigkeit darüber, dass man hier und da eine
Leerzeile zur Gruppierung der einzelnen Codeabschnitte einfügt.

Übrigens: Romane enthalten i.Allg. keine Leerzeilen zwischen den
Absätzen. Es geht also durchaus auch ohne ;-)

> Und moeglichst viele Abkuerzungen. Hauptsache, viel Text auf einer
> Seite.

Eben möglichst viel, so dass aber die Übersicht gerade noch erhalten
bleibt. Anders machen es die Buchautoren auch nicht.

Yalu X. schrieb:
> Anders machen es die Buchautoren auch nicht.

Kommt drauf an. Wenn sie nach Seiten bezahlt werden ...

Johann L. schrieb:
> Michael L. schrieb:
>> Yalu X. schrieb:
>>> Michael L. schrieb:
>>>> Warum das nur genau so richtig ist, werdet ihr merken wenn ihr
>>>> 1. mal mit einer Versionsverwaltung gearbeitet habt.
>>>
>>> [...]
>>>
>>
>> Nun ja, der Versionsverwaltung ist die Klammersetzung auch pupsegal.
>
> Zitat Onkel Wiki:
>
>>> Für VCS-Tools ist dieser Stil problematisch. Fügt man ein neues
>>> Statement zwischen dem "{" und dem ersten Statement ein, erscheint
>>> diese Änderung als "eine Zeile wird durch 2 Zeilen ersetzt" statt
>>> "eine neue Zeile wurde eingefügt". Das heißt, die ursprüngliche Zeile
>>> wird als "geändert" markiert, obwohl sie semantisch gleich geblieben ist.

Ich möchte dich bitten, in Zukunft mal Beiträge zu Ende zu lesen, und 
Zitate nicht aus dem Zusammenhang zu reißen. Danke!

Auf die Problematik hatte ich schon hingewiesen. Trotz dem ist das 
Wiki-Zitat insofern falsch, weil letztendlich das Problem beim User 
landet. Die Versionsverwaltung zeigt nur das, was sie sieht ...

Grüße.

Yalu X. schrieb:
> Michael L. schrieb:
>> Aber wenn du ein diff machst, dann werden die Unterschiede sehr schnell
>> unübersichtlich, wenn, was gar nicht so selten der Fall ist, am Anfang
>> oder Ende eines geklammerten Code-Blocks noch ein Statement eingefügt
>> werden muss.
>
> Ok, das ist ein Argument. Wobei ein vernünftiges Diff-/Merge-Tool ja
> nicht nur geänderte Zeilen anzeigt, sondern auch die Unterschiede
> innerhalb von Zeilen.

Ich verwende auch nur solche Tools, die das können. Aber trotz allem 
leidet die Übersichtlichkeit eben ganz erheblich.

Grüße.

Ingo schrieb:
> Welche Schreibweise gestaltet sich bei viel Code eurer Meinung
> übersichtlicher?
Die erste. Weil ich zwischenzeitlich zwar unglaublich brrrreeeeiiite 
Monitore bekomme, aber leider mit nur sehr geringer Bildschimhöhe.

Und eine Funktion, die nicht auf 1 Bildschirmseite passt, ist schon per 
Definition unübersichtlich, weil nicht überschaubar...

Yalu X. schrieb:
> Marwin schrieb:
>> Ich frage mich, ob ihr Buecher lesen wuerdet, die die Autoren nach euren
>> Regeln geschrieben haben.
>
> Wahrscheinlich nicht, weil sie so viel Whitespace enthielten, dass ein
> 200-seitigen Taschenbuch schnell zu einem 5-bändigen Werk mit 800 Seiten
> pro Band explodieren würde. Das wäre mir einfach zu teuer.

Ich find wie Marwin auch — unabhängig vom Code-Stil — dass die meisten 
Beispiele ziemlich quetschig wirken: Möglicht viel Code auf kleinem 
Raum, zumindest die starke Tendenz dazu.

Text-Layout (und zu Text gehört auch Quelltext) sollte sich auch nach 
typographischen Grundregeln richten.

Code aneinanderzuklatschen und mit Leerzeilen zu geizen hilft der 
leserlichkeit nicht.  Den Überblick über den Text bekommt man dich eine 
klare Strukturieren zusammen mit aussagekräftigen Kommentaren.

Möglichst viel auf eine Seite zu bekommen ist m.M. bringt m.M. kein 
Gewinn an Übersichtlichkeit.

Als ich mit avr-gcc anfing hab ich mit zum Beispiel den Code von anderen 
Backends angeschaut.

Alle Backends folgen dem gleichen Code-Stil; dennoch war ich sehr 
übberrascht, wie unterschiedlich Lesbarkeit und Verständlichkeit 
unterschiedlichen Backends ist.  Bei meinen Beiträgen versuche ich nun 
auch, ähnlich angenehm lesbaren Code zu erstellen.

Für eine Datei (avr.c) hab ich mal eine kleine Statistik gemacht:

Zeilen insgesamt                   : 10869
Leerzeilen (auch in Kommentaren)   :  1918
Kommentare (ohne Leerzeilen)       :   666
Zeilen, die nur { enthalten        :   639
Zeilen, die nur } enthalten, incl. :   642
              };  und } /* ... */

Der Code besteht also zu 30% aus Leerzeilen und Zeilen, die nur "{" oder 
"}" enthalten.

Werden auch Kommentare zu diesem "nutzlosem" Code gezählt, erhöht sich 
dessen Anteil an den Quellzeilen auf 36%.

Neben der Formatierung des Codes spielt aber auch das 
Syntax-Highlighting eine entscheidende Rolle für ein Ermüdungsarmes 
Arbeiten mit dem Text.

Eine Hilit-Einstellung, die alle paar Schlüsselworte zu einem anderen 
Schriftschnitt wechselt, lässt den Text schlimm die Bild-Zeitung 
aussehen.

Ein dezentes Einfärben des Codes zusammen mit gutem Textlayout ist 
vollkommen ausreichend, wenn man einen Zeichensatz wählt, der gut 
unterscheidbare Zeichen hat, d.h. Il1| usw. sind leicht und ohne 
Verwechslungsgefahr zu unterscheiden, ditto für  0 und O und ähnliche 
Fälle.

Last not least der Editor selbst: Ein Editor, der einen bestimmten 
Code-Stil nicht oder nur mühsam unterstützt, ist nervig.  Es geht dann 
viel Zeit drauf, die Einrückungen wieder hinzubiegen.  Oft sieht man das 
beim

- Öffnen eines neuen Blocks
- Schliessen eines Blocks
- Brechen langer Zeilen (In Makros, Parameterlisten, Klauseln, ...)
- Einrückung mehrzeiliger Makros
- Fehlende Möglichkeit, Leerzeichen statt TABs zum Einrücken zu
  verwenden
- Automatisches Einrücken einzelner Zeilen oder Blöcke anhand des
  aktiellen Stils und etvtl. auch passend zum Kontext, etwa korrektes
  Einrücken von Code-Schnippel in Kommentaren.

> Anders machen es die Buchautoren auch nicht.

Ich behaupte mal der Autor eines Romans hat mit dessen Schriftsatz und 
Typographie rein garnix zu tun :-)

Leider sieht es so aus, als wären Typographie sowie Text- und Bildsatz 
bei vielen Seitenbetreibern ziemlich egal :-(

Lothar Miller schrieb:

> Die erste. Weil ich zwischenzeitlich zwar unglaublich brrrreeeeiiite
> Monitore bekomme, aber leider mit nur sehr geringer Bildschimhöhe.

dann hast du Dir einfach einen falschen gekauft. Mein Notebook  hat 1200 
in der Höhe und das ist auch gut so. Und darum darf ich mir auch den 
übersichtlicheren 2ten Programmierstiel erlauben. 64Zeilen sind schon 
was feines. am Desktop hab ich über 80 Zeilen. als Programmierer achtet 
man eben darauf was man sich besorgt und ob man damit arbeiten oder 
spielen will.
 Auf dem Tablet hab ich die zwar nicht, aber das kann man ja auch drehen 
und dann hab ich sogar noch etwas mehr in der Höhe.

> Und eine Funktion, die nicht auf 1 Bildschirmseite passt, ist schon per
> Definition unübersichtlich, weil nicht überschaubar...
 Ich persönlich bin der Meinung das ein Sinnabschnitt nicht drüber gehen 
sollte von dem es durchaus mehrere in einer Funktion geben darf. Wobei 
damit gemeint ist ein Block auf sehr kleiner Verschachtungstiefe.

func()
{
  { grosser sinnblock }
  { noch nen grosser oder kleiner }
  { evt noch einer }
}
 ... aber hängt auch vom Projekt ab wie man es macht.


Autor: W.S. (Gast) schrieb
>So richtig zur Hochform kommt die obige Schreibweise aber erst dann,
>wenn man Quellen hat, wo jemand einem einen richtigen Haufen
>geschachtelter Blöcke unterschiedlichster Machart hinterlassen hat
 Es war dann meist nicht jemand, obwohl es solche Leute auch gibt, 
sondern verschiedene Leute, die meinten ihren eignen Stil einbringen zu 
müssen. (solche Leute sollte man direkt erschießen äähm entlassen)

 Ein absolutes NOGO ist wenn ein Format in einem Source existiert, dann 
in einem anderen Stil weiterzuschreiben. Wenn ein Stil vorgegeben ist, 
ist dieses auch beizubehalten und so weiterzumachen, oder man formatiert 
den ganzen Source um.

Mikel M. schrieb:
> Lothar Miller schrieb:
>
>> Die erste. Weil ich zwischenzeitlich zwar unglaublich brrrreeeeiiite
>> Monitore bekomme, aber leider mit nur sehr geringer Bildschimhöhe.
>
> dann hast du Dir einfach einen falschen gekauft. Mein Notebook  hat 1200
> in der Höhe und das ist auch gut so.

Das ist sogar sehr gut. Aber wo gibt es solche Notebooks heute noch zu
kaufen, außer im Trödelladen?

Ich habe zwei 1200er-Notebooks, ein altes und ein uraltes. Wenn ich
wollte, könnte ich vielleicht auch noch ein ururaltes bekommen. Gerne
würde ich mal wieder ein neues haben. Aber leider ist es bei den
Notebooks wie bei den abgepackten Lebensmitteln: Die Preise bleiben zwar
die gleichen, aber man bekommt 10% weniger Inhalt.

Mikel M. schrieb:
> Ein absolutes NOGO ist wenn ein Format in einem Source existiert, dann
> in einem anderen Stil weiterzuschreiben. Wenn ein Stil vorgegeben ist,
> ist dieses auch beizubehalten und so weiterzumachen, oder man formatiert
> den ganzen Source um.

Volle Zustimmung!

Yalu X. schrieb:
> Mal etwas avantgardistisch:
> if(x>5)                                                                {
>   a = 0                                                               ;
>   b = 1                                                               ;}
> else                                                                   {
>   a = 2                                                               ;
>   b = 3                                                               ;}
> funktion(a, b)                                                        ;
>
> Alle hässlichen Semikola und geschweiften Klammern werden dorthin ver-
> bannt, wo sie das Auge kaum noch stören, vom Compiler aber noch gesehen
> werden.

Mit etwas Kreativität kann man die geschweiften Klammern ganz 
eliminieren. Den folgenden Code habe ich nicht getestet, aber er 
compiliert zumindest ohne Fehlermeldung.

1

#define then {

2

#define endif }

3

#define else }else{

4

5

void test(int i){

6

  if (i==1) then

7

    PORTC += 1;

8

    PORTD += 1;

9

  else

10

    PORTC -= 1;

11

    PORTD -= 1;

12

  endif

13

}