if if else if - ohne geschweifte Klammern

[ifesel (Gast)]

Hi,

auf welches if-else Statement bezieht sich eigentlich ein if if else if 
Konstrukt ohne geschweifte Klammern... auf das erste oder letzte if?
... müsste ja dann immer das erste oder letze if sein, auch wenn es noch 
mehr sind.

int a = 0;
int b = 0;
if (a > 0) foo(a);
          if (b > 0) foo(b);
  <-> else...a <= 0 oder b <= 0 ?

[pegel (Gast)]

ifesel schrieb:
> if (a > 0) foo(a);

ist mit dem Semikolon abgeschlossen, da bleibt nichts offenes.

[ifesel (Gast)]

und ohne ;

[Irgend W. (Firma: egal) (irgendwer)]

if (a > 0)
{
  foo(a);
}

if (b > 0)
{
  foo(b);
}
else
{
  ...
}

Das else bezieht sich auf das direkt davor stehende if.
Das erste if ist mit dem ersten Funktionsaufruf abgeschlossen und alles 
weitere danach hat nichts mehr damit zu tun.

[pegel (Gast)]

Ohne ; wäre es in dem Fall ein Syntaxfehler.

https://www.youtube.com/watch?v=6QgWvdxGRzY

[ifesel (Gast)]

Danke :-)

[popelnder corona patient (Gast)]

Aber mal ehrlich: Wer programmiert denn absichtlich in so einem 
beschissenen Stil??

[Andreas B. (bitverdreher)]

wie meinen?

[A. S. (Gast)]

Andreas B. schrieb:
> wie meinen?

Man setzt Klammern zumindest so lange, bis man mit dem Rest mehr Übung 
hat und z.b. vertrauter mit dem ; ist.

[Sebastian (Gast)]

pegel schrieb:
> ifesel schrieb:
> if (a > 0) foo(a);
>
> ist mit dem Semikolon abgeschlossen, da bleibt nichts offenes.

pegel schrieb:
> ifesel schrieb:
> if (a > 0) foo(a);
>
> ist mit dem Semikolon abgeschlossen, da bleibt nichts offenes.

Blödsinn.

[Andreas B. (bitverdreher)]

A. S. schrieb:
> Andreas B. schrieb:
>> wie meinen?
>
> Man setzt Klammern zumindest so lange, bis man mit dem Rest mehr Übung
> hat und z.b. vertrauter mit dem ; ist.

Na gut, darüber kann man streiten, aber bei nur einem Befehl mache ich 
da auch keine Klammer. Das schreibe ich genauso wie oben. Schlechter 
Programmierstil sieht für mich anders aus.

[Georg M. (g_m)]

"Ein unbegrenzter Vorrat von geschweiften Klammern"

https://www.stupidedia.org/stupi/C_(Programmiersprache)

[popelnder corona patient (Gast)]

Andreas B. schrieb:
> Na gut, darüber kann man streiten, aber bei nur einem Befehl mache ich
> da auch keine Klammer. Das schreibe ich genauso wie oben. Schlechter
> Programmierstil sieht für mich anders aus.

Nö. Das ist einfach fehleranfällige gequirlte Kacke. So und nicht 
anders:

if(bla) {
  std::cout << "Bla" << std::endl;
}
else {
  std::cout << "Blub" << std::endl;
}

[Stefan F. (Gast)]

Wer sich beim Schreiben von C-Quelltext die Finger verdreht, sollte man 
eine englische Tastatur probieren. Dort sind alle häufig verwendeten 
Sonderzeichen der Programmiersprache (auch geschweifte Klammern) 
bequemer einzutippen.

[Klaus (Gast)]

Andreas B. schrieb:
> Na gut, darüber kann man streiten, aber bei nur einem Befehl mache ich
> da auch keine Klammer. Das schreibe ich genauso wie oben. Schlechter
> Programmierstil sieht für mich anders aus.

Und dann kommt zum Testen noch ein print (oder etwas anderes) dazu, und 
schon sucht man einen falschen Fehler. Da das in C wohl so oft vorkommt, 
hat man in Perl die Klammern zur Pflicht gemacht.

MfG Klaus

[Andreas S. (marais)]

popelnder corona patient schrieb:
> if(bla) {
>   std::cout << "Bla" << std::endl;
> }
> else {
>   std::cout << "Blub" << std::endl;
> }


Stilfragen sind Geschmackssache. Wärst Du bei Bill Gates angestellt, 
müsstest Du schreiben:

if(bla)
{
  std::cout << "Bla" << std::endl;
}
else
{
  std::cout << "Blub" << std::endl;
}

Und wäre Dennis Ritchie Dein Chef, müsste es so heissen

cstring blablub = (bla) ? "bla" : "blub";
std::cout << blablub << std::endl;

[Falk B. (falk)]

Klaus schrieb:
> Und dann kommt zum Testen noch ein print (oder etwas anderes) dazu, und
> schon sucht man einen falschen Fehler. Da das in C wohl so oft vorkommt,
> hat man in Perl die Klammern zur Pflicht gemacht.

Eben.

Strukturierte Programmierung auf Mikrocontrollern

https://www.mikrocontroller.net/articles/Datei:CodeStyleConventions_ID_Software.pdf

[C Leerer (Gast)]

Bei dieser höchst passenden Gelegenheit möchte ich alle Spaghetti-
und ähnliche Programmierer darauf hinweisen wie man wirklich
richtig gut programmiert.

Hier die Anleitung dazu (sie spricht mir aus der Seele):

https://www.se.rit.edu/~tabeec/RIT_441/Resources_files/How%20To%20Write%20Unmaintainable%20Code.pdf

Sie wird nicht jeder verstehen, aber wenn es ein paar wenige
sind freue ich mich schon darüber ...

[Andreas B. (bitverdreher)]

Georg M. schrieb:
> "Ein unbegrenzter Vorrat von geschweiften Klammern"
>
> https://www.stupidedia.org/stupi/C_(Programmiersprache)

Nice! ;-)

Klaus schrieb:
> Und dann kommt zum Testen noch ein print (oder etwas anderes) dazu, und
> schon sucht man einen falschen Fehler. Da das in C wohl so oft vorkommt,
> hat man in Perl die Klammern zur Pflicht gemacht.

Das passiert nicht (oder eher nicht), wenn man den Befehl ohne Klammer 
in die gleiche Zeile schreibt.
Ich seĺbst achte und schaue bei C eigentlich mehr auf die Einrückungen. 
Wenn die allerdings nicht stimmen, dann hat man ein Problem.

[Rolf M. (rmagnus)]

Ich mache auch keine Klammern, aber nur dann, wenn es sowohl im if-, als 
auch (sofern vorhanden) im else-Teil jeweils nur genau eine Zeile gibt. 
Falls in einem der beiden Zweige mehr als eine Zeile vorkommt, mache ich 
für beide Klammern hin.

popelnder corona patient schrieb:
> Nö. Das ist einfach fehleranfällige gequirlte Kacke. So und nicht
> anders:
> if(bla) {
>   std::cout << "Bla" << std::endl;
> }
> else {
>   std::cout << "Blub" << std::endl;
> }

Ich finde diese Asymmetrie bei öffnender und schließender Klammer 
irgendwie unübersichtlich (oder von mir aus auch "gequirlte Kacke"), 
auch wenn man sie recht häufig sieht.
Die öffnende Klammer würde bei mir daher so wie die schließende eine 
eigene Zeile bekommen und in der gleichen Spalte stehen.

Klaus schrieb:
> Und dann kommt zum Testen noch ein print (oder etwas anderes) dazu, und
> schon sucht man einen falschen Fehler.

Nö, warum? Ich hab ja Augen im Kopf und ordentlich eingerückt. Wenn ich 
dann doch Klammern brauche, sehe ich das doch.

Andreas B. schrieb:
> Klaus schrieb:
>> Und dann kommt zum Testen noch ein print (oder etwas anderes) dazu, und
>> schon sucht man einen falschen Fehler. Da das in C wohl so oft vorkommt,
>> hat man in Perl die Klammern zur Pflicht gemacht.
>
> Das passiert nicht (oder eher nicht), wenn man den Befehl ohne Klammer
> in die gleiche Zeile schreibt.
> Ich seĺbst achte und schaue bei C eigentlich mehr auf die Einrückungen.
> Wenn die allerdings nicht stimmen, dann hat man ein Problem.

Wobei heutige gcc-Versionen durchaus auch mal eine Warnung aussprechen, 
wenn die Einrückung missverständlich ist. Und speziell dieser Fall ist 
davon abgedeckt:

#include <stdio.h>

int func(int a, int b)
{
    if (a < b)
        printf("A ist kleiner als b\n");
        return a;
    return b;
}

führt bei -Wall zu folgender Ausgabe des Compilers:

indentation.c: In function ‘func’:
indentation.c:5:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
    5 |     if (a < b)
      |     ^~
indentation.c:7:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’

[Stefan F. (Gast)]

Rolf M. schrieb:
> Die öffnende Klammer würde bei mir daher so wie die schließende eine
> eigene Zeile bekommen und in der gleichen Spalte stehen.

Ich habe mich daran gewöhnt, darüber nicht mehr nachzudenken. Das macht 
jeder so wie er will - ebenso die Schrittweite von Tabulatoren und die 
Anzahl der Leerzeilen.

Entweder schreibt der Chef etwas vor, oder man nimmt diese individuellen 
Unterschiede als gegeben hin. Darüber zu diskutieren lohnt sich nicht.

[Andreas B. (bitverdreher)]

Rolf M. schrieb:
>> if(bla) {
>>   std::cout << "Bla" << std::endl;
>> }
>> else {
>>   std::cout << "Blub" << std::endl;
>> }
>
> Ich finde diese Asymmetrie bei öffnender und schließender Klammer
> irgendwie unübersichtlich

Das finde ich sowieso schräg. (und das gerade von jemanden, der sich 
über gequirlte Kacke beschwert).

Ich mache das gewöhnlicherweise so:
if(bla) {
  std::cout << "Bla" << std::endl;
} else {
  std::cout << "Blub" << std::endl;
}

Diese Standardmethode:
if(bla)
{
  std::cout << "Bla" << std::endl;
}
else
{
  std::cout << "Blub" << std::endl;
}

die ich des öfteren sehe gefällt mir überhaupt nicht, da sie zu viel 
Platz auf den Monitor benötigt.
Ja, ja, ich sollte mir einen 27" Monitor kaufen. Mein Problem dabei ist: 
Mein 24" Eizo will nicht kaputtgehen.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> Darüber zu diskutieren lohnt sich nicht.

Doch!
Den über nichts anderes kann man so feine Grabenkriege anzetteln, als 
über Geschmacksfragen und persönliche Vorlieben.

[Rolf M. (rmagnus)]

Stefan ⛄ F. schrieb:
> Rolf M. schrieb:
>> Die öffnende Klammer würde bei mir daher so wie die schließende eine
>> eigene Zeile bekommen und in der gleichen Spalte stehen.
>
> Ich habe mich daran gewöhnt, darüber nicht mehr nachzudenken.

Was ich damit vor allem sagen wollte, war, dass solche Dinge 
Geschmackssache sind. Was Programmierer A als

popelnder corona patient schrieb:
> gequirlte Kacke

bezeichnet, ist für Programmierer B ganz normal, dafür findet der eben 
etwas am Stil von Programmierer A schlecht. Es gibt eben keine 
objektiven Kriterien für "Lesbarkeit" oder "Fehleranfälligkeit".

> Das macht jeder so wie er will - ebenso die Schrittweite von Tabulatoren und
> die Anzahl der Leerzeilen.

Ja. Ich war bisher sowohl privat als auch geschäftlich immer in der 
glücklichen Lage, das selbst bestimmen zu können.

> Entweder schreibt der Chef etwas vor, oder man nimmt diese individuellen
> Unterschiede als gegeben hin. Darüber zu diskutieren lohnt sich nicht.

Ja, da hast du natürlich recht. Man lebt deutlich entspannter, wenn man 
solche Vorgaben einfach als gegeben hinnimmt, als wenn man sich darüber 
aufregt oder versucht, darüber zu diskutieren.

[popelnder corona patient (Gast)]

Das hat doch absolut nichts mit Stil mehr zu tun, da muss ich mich 
selber korrigieren. Geschweifte Klammern bei if/else weglassen ist *grob 
fahrlässig*. Dass das überhaupt möglich ist, das ist eigentlich der 
Skandal.

[Andreas B. (bitverdreher)]

popelnder corona patient schrieb:
> Das hat doch absolut nichts mit Stil mehr zu tun, da muss ich mich
> selber korrigieren. Geschweifte Klammern bei if/else weglassen ist *grob
> fahrlässig*. Dass das überhaupt möglich ist, das ist eigentlich der
> Skandal.

Du wirst Dich noch mehr darüber aufregen, daß man bei C für jeden 
Anweisungsblock die geschweiften Klammern weglassen kann, wenn er nur 
aus einem Befehl besteht.

Rolf M. schrieb:
> Man lebt deutlich entspannter, wenn man
> solche Vorgaben einfach als gegeben hinnimmt, als wenn man sich darüber
> aufregt oder versucht, darüber zu diskutieren.

Ich bin ziemlich entspannt. ;-)

[Rolf M. (rmagnus)]

popelnder corona patient schrieb:
> Das hat doch absolut nichts mit Stil mehr zu tun, da muss ich mich
> selber korrigieren.

Es ist ausschließlich eine Stilfrage und nichts anderes.

> Geschweifte Klammern bei if/else weglassen ist grob fahrlässig.

Für dich vielleicht. Ich hatte damit in >25 Jahren C- und 
C++-Programmierung nie ein Problem.

Andreas B. schrieb:
> Du wirst Dich noch mehr darüber aufregen, daß man bei C für jeden
> Anweisungsblock die geschweiften Klammern weglassen kann, wenn er nur
> aus einem Befehl besteht.

Naja, nicht bei jedem. Bei einer Funktion muss man die Klammern dann 
doch immer setzen.

[Stefan F. (Gast)]

popelnder corona patient schrieb:
> Das hat doch absolut nichts mit Stil mehr zu tun, da muss ich mich
> selber korrigieren. Geschweifte Klammern bei if/else weglassen ist *grob
> fahrlässig*.

Bei dem Stil ging es darum, wo die Klammern positioniert werden. Dass 
man sie nicht weglassen soll (außer eventuell bei Einzeilern ohne else), 
darüber sind wir uns offenbar einig.

[foobar (Gast)]

> Geschweifte Klammern bei if/else weglassen ist grob fahrlässig.

Dann möchte ich bei dir mal ein "else-if" sehen, oder besser noch 
mehrere ;-)

[popelnder corona patient (Gast)]

Rolf M. schrieb:
> Es ist ausschließlich eine Stilfrage und nichts anderes.

Lass es mich so formulieren: Wenn ich einen Angestellten entdecke, der 
die geschweiften Klammern weglässt, der wird ordentlich getadelt und es 
gibt Anweisung das zu unterlassen ... so viel zur Stilfrage. Dass man 
bei C/C++ geschweifte Klammern niemals weglässt lernt hoffentlich 
heute jeder Student.

[merciMerci (Gast)]

popelnder corona patient schrieb:
> so viel zur Stilfrage.

hier als popelnder corona patient von stil reden, ziehmlich grob!

[Zeno (Gast)]

popelnder corona patient schrieb:
> Lass es mich so formulieren: Wenn ich einen Angestellten entdecke, der
> die geschweiften Klammern weglässt, der wird ordentlich getadelt und es
> gibt Anweisung das zu unterlassen ... so viel zur Stilfrage. Dass man
> bei C/C++ geschweifte Klammern niemals weglässt lernt hoffentlich
> heute jeder Student.

Na da bin ich aber froh das ich nicht so einen Chef habe.

[popelnder corona patient (Gast)]

foobar schrieb:
> Dann möchte ich bei dir mal ein "else-if" sehen, oder besser noch
> mehrere ;-)

Bei mir gibts nur if-schleifen!

[Andreas B. (bitverdreher)]

Zeno schrieb:
> Na da bin ich aber froh das ich nicht so einen Chef habe.

Geh mal davon aus daß er kein Chef von irgendjemanden ist.

[S. R. (svenska)]

Rolf M. schrieb:
> Die öffnende Klammer würde bei mir daher so wie die schließende eine
> eigene Zeile bekommen und in der gleichen Spalte stehen.

Das kostet vertikal Platz und erhöht damit die Wahrscheinlichkeit, dass 
die Funktion nicht mehr auf den Bildschirm passt (v.a. Breitbild sei 
dank).

FreeBSD hatte das mal untersucht und ist zu dem Schluss gekommen, dass 
"die Funktion passt nicht mehr auf den Bildschirm" die 
Wahrscheinlichkeit von Bugs pro Zeile um den Faktor 10 erhöht.

Ansonsten ist es Geschmackssache.

[rcc (Gast)]

Andreas B. schrieb:
> Zeno schrieb:
>> Na da bin ich aber froh das ich nicht so einen Chef habe.
>
> Geh mal davon aus daß er kein Chef von irgendjemanden ist.

oder er arbeitet in einem Bereich in dem MISRA C gesetzt ist

[Einer K. (Gast)]

S. R. schrieb:
> Das kostet vertikal Platz und erhöht damit die Wahrscheinlichkeit, dass
> die Funktion nicht mehr auf den Bildschirm passt (v.a. Breitbild sei
> dank).

Ich bevorzuge den "Allman Stil" welcher auch "BSD Stil" genannt wird.
Eben weil dann die Blockklammern vertikal übereinander stehen.
Aus meiner Sicht erhöht das die Übersicht wesentlich.
Zumindest über die Blockklammern.
Viele Editoren können die eine Blockklammer blinken lassen (oder anders 
erleuchten), wenn man die andere antickt.
Dann sieht man sofort, wenn was falsch läuft, sie nicht in einer Linie 
übereinander stehen.

S. R. schrieb:
> FreeBSD hatte das mal untersucht und ist zu dem Schluss gekommen, dass
> "die Funktion passt nicht mehr auf den Bildschirm" die
> Wahrscheinlichkeit von Bugs pro Zeile um den Faktor 10 erhöht.
Naja...
Das glaube ich erst, wenn ich die Begründungen gesehen habe

S. R. schrieb:
> Ansonsten ist es Geschmackssache.
Mal abgesehen von Team Doktrin, Firmen Weisungen, ja.

[Rolf M. (rmagnus)]

popelnder corona patient schrieb:
> Rolf M. schrieb:
>> Es ist ausschließlich eine Stilfrage und nichts anderes.
>
> Lass es mich so formulieren: Wenn ich einen Angestellten entdecke, der
> die geschweiften Klammern weglässt, der wird ordentlich getadelt und es
> gibt Anweisung das zu unterlassen ... so viel zur Stilfrage.

Es bleibt eine Stilfrage, ganz unabhängig davon, ob du zum Choleriker 
wirst, wenn jemand eine Klammer nicht setzt. Ich halte so ein Vorgehen 
jedenfalls für eine gute Arbeitsatmosphäre für wenig zweckmäßig.
Viele haben das Problem, dass sie ihre Meinung für eine unumstößliche 
Tatasche halten und deshalb nicht in der Lage sind, andere Meinungen 
überhaupt erst zu akzeptieren.

S. R. schrieb:
> Rolf M. schrieb:
>> Die öffnende Klammer würde bei mir daher so wie die schließende eine
>> eigene Zeile bekommen und in der gleichen Spalte stehen.
>
> Das kostet vertikal Platz und erhöht damit die Wahrscheinlichkeit, dass
> die Funktion nicht mehr auf den Bildschirm passt (v.a. Breitbild sei
> dank).

Ja. Ich finde es trotzdem insgesamt übersichtlicher.

> FreeBSD hatte das mal untersucht und ist zu dem Schluss gekommen, dass
> "die Funktion passt nicht mehr auf den Bildschirm" die
> Wahrscheinlichkeit von Bugs pro Zeile um den Faktor 10 erhöht.
>
> Ansonsten ist es Geschmackssache.

Ja, genau das ist der Punkt: Es ist Geschmackssache.

Arduino Fanboy D. schrieb:
> S. R. schrieb:
>> FreeBSD hatte das mal untersucht und ist zu dem Schluss gekommen, dass
>> "die Funktion passt nicht mehr auf den Bildschirm" die
>> Wahrscheinlichkeit von Bugs pro Zeile um den Faktor 10 erhöht.
> Naja...
> Das glaube ich erst, wenn ich die Begründungen gesehen habe

Ich frage mich auch, ob man sowas überhaupt unabhängig von anderen 
Faktoren gesehen werden kann.

[Stefan F. (Gast)]

Warum sollte ich großartig mit meinen Kollegen über die Positionierung 
der Klammern diskutieren? Ein einheitlicher Stil macht den Quelltext 
besser lesbar, deswegen sollte man sich einigen. Aber welcher Stil das 
dann am Ende ist ... ich sorge mich lieber um die Familie mit Kindern, 
als um so eine Pillepalle.

[Zeno (Gast)]

Andreas B. schrieb:
> Zeno schrieb:
>> Na da bin ich aber froh das ich nicht so einen Chef habe.
>
> Geh mal davon aus daß er kein Chef von irgendjemanden ist.

Dann wäre es ja ein Wichtigtuer.

[Zeno (Gast)]

Arduino Fanboy D. schrieb:
> Ich bevorzuge den "Allman Stil" welcher auch "BSD Stil" genannt wird.
> Eben weil dann die Blockklammern vertikal übereinander stehen.
> Aus meiner Sicht erhöht das die Übersicht wesentlich.
> Zumindest über die Blockklammern.
> Viele Editoren können die eine Blockklammer blinken lassen (oder anders
> erleuchten), wenn man die andere antickt.

Sehe ich genauso und deshalb bevorzuge ich diese Schreibweise auch, auch 
bei anderen Programmiersprachen (z.B. Pascal).
Aber hast ja gelesen der Blockbeginn muß gleich hinter dem Statement 
stehen sonst gibt es auf die Mütze (s. hier 
Beitrag "Re: if if else if - ohne geschweifte Klammern").

[Vincent H. (vinci)]

Der Thread beweist eindrucksvoll wieso moderne Sprachen ein auto-format 
ohne jegliche Optionen besitzen. Die Rust-Community etwa muss sich mit 
so dummen Diskussionen nicht quälen...

[Andreas B. (bitverdreher)]

Ich wußte gar nicht daß diese Stile Namen haben.
Dann verwende ich ja den von höchster Stelle (Kernighan & Ritchie) 
verwendeten 1TBS Stil. Da haben wir aber Glück, daß die beiden nicht bei 
popelnder corona patient angestellt sind. ;-)

[Bauform B. (bauformb)]

Ich hoffe ja stark, dass der popelnde corona patient die Minuspunkte für 
das Popeln bekommt. if ohne geschweifte Klammern ist keine 
Geschmackssache sondern Sabotage und eine Gemeinheit gegen die 
Kollegen.

[HildeK (Gast)]

Ein herrliches Thema für eine endlose Diskussion über persönlichen 
Vorlieben ?.

Ich mache es trotzdem so, wie es mir gefällt und wie ich es für mich am 
Besten lesbar halte.
Da gibt es Einzeiler ohne Klammern und bei den Mehrzeilern stehen die 
schön in der selben Spalte in einer eigenen Zeile.
Ich habe aber den Vorteil, privater Gelegenheitsprogrammierer zu sein 
...

Andreas B. schrieb:
> Ich mache das gewöhnlicherweise so:
> if(bla) {
>   std::cout << "Bla" << std::endl;
> } else {
>   std::cout << "Blub" << std::endl;
> }
Für mich ist das fast unlesbar, verbunden mit der ewigen Suche nach den 
beiden Klammern. Das ist vor allem bei längeren Blöcken der Fall. Mag 
sein, dass es nur gewöhnungsbedürftig ist.
Bei einfachen 'Einzeilern' ist mir selbst diese Variante noch lieber:
  if (bla) { a=5; b=3; }
  else     { a=0; b=1; }
weil auf den ersten Blick erfassbar.

[Andreas B. (bitverdreher)]

Bauform B. schrieb:
> Ich hoffe ja stark, dass der popelnde corona patient die Minuspunkte für
> das Popeln bekommt.
nö, die bekam er schon für das "grob fahrlässig".
Es soll ja auch Leute geben, die C an sich schon gemein finden.

HildeK schrieb:
> Ein herrliches Thema für eine endlose Diskussion über persönlichen
> Vorlieben ?.
+1 ;-)

HildeK schrieb:
> Andreas B. schrieb:
>> Ich mache das gewöhnlicherweise so:
>> if(bla) {
>>   std::cout << "Bla" << std::endl;
>> } else {
>>   std::cout << "Blub" << std::endl;
>> }
> Für mich ist das fast unlesbar, verbunden mit der ewigen Suche nach den
> beiden Klammern.
Ich schaue dabei hauptsächlich nach den Einrückungen.

[HildeK (Gast)]

Andreas B. schrieb:
> Ich schaue dabei hauptsächlich nach den Einrückungen.

Ich wollte nicht dich persönlich kritisieren, ich habe nur dein Beispiel 
genommen. Wie gesagt: wichtig ist es, dass es für mich persönlich leicht 
lesbar ist, wie auch immer ich es erreiche. Du bevorzugst eine andere 
Methode; genauso ok.
Da ich mich keinem Team 'unterwerfen' muss, gibt es auch keine 
Konflikte. Nur wenn ich deinen Code lese oder du meinen, dann wird es 
halt für uns beide unübersichtlicher.

Andreas B. schrieb:
> Es soll ja auch Leute geben, die C an sich schon gemein finden.

Ein Tutor in meiner frühen Anfangszeit meinte mal: in C zu programmieren 
ist wie ein offenes Rasiermesser in der Hose zu haben ...

[Andreas B. (bitverdreher)]

HildeK schrieb:
> Ich wollte nicht dich persönlich kritisieren, ich habe nur dein Beispiel
> genommen.
Ich habe es auch nicht so aufgefaßt.

> Da ich mich keinem Team 'unterwerfen' muss, gibt es auch keine
> Konflikte.
dto. In diesem Fall würde ich mich auch mit meinen Kollegen 
zusammensetzen und einen Stil für alle definieren.

HildeK schrieb:
> Nur wenn ich deinen Code lese oder du meinen, dann wird es
> halt für uns beide unübersichtlicher.
Bei uns gäbe es tatsächlich Probleme. Dein Beispiel mit den Einzeilern 
fand ich gruselig. ;-)

[HildeK (Gast)]

Andreas B. schrieb:
> Bei uns gäbe es tatsächlich Probleme. Dein Beispiel mit den Einzeilern
> fand ich gruselig. ;-)

Ja, nehme ich zur Kenntnis. Normalerweise würde es aber so aussehen:
  if (bla)
  {
     a=5;
     b=3;
  }
  else
  {
     a=0;
     b=1;
  }
Und jetzt ist schon die halbe Seite voll, ohne besser lesbar zu sein.
Nochmal: sobald in dem Block mehr und größere Anweisungen stehen, mache 
ich es nicht so wie in dem 'gruseligen' Beispiel.

[merciMerci (Gast)]

... Geschmack berührt immer!

anderes Beispiel:

//my approach, easy to detect
while (...) continue;

//other variants
while (...);
while (...) {}
while (...)
  ;
while (...)
  {}

[Yalu X. (yalu) (Moderator)]

Meine persönliche Meinung zur Quellcodeformatierung:

Geschweifte Klammern sind für Compiler und Autoformatierer gamacht, der
Programmierer orientiert sich bevorzugt an den Einrückungen.

Wichtigste Kriterien für gute Übersichtlichkeit und Lesbarkeit:

1. Es sollte möglichst viel Code auf einmal im Editorfenster sichtbar
   sein (aber nicht um jeden Preis).

2. Die Zeilenlänge sollte auf ca. 80 bis 120 Zeichen beschränkt sein,
   auch wenn der Bildschirm wesentlich mehr hergibt.

3. Längere Codeabschnitte sollten mittels Leerzeilen logisch gruppiert
   werden.

4. Besonderheiten im Kontrollfluss (Verzweigungen und Schleifen) sollten
   auch beim schnellen Überfliegen auffallen, ohne dass man explizit
   nach den zugehörigen Schlüsselwörtern Ausschau halten muss.

(2), (3) und (4) stehen im Widerspruch zu (1), weswegen ein sinnvoller
Kompromiss gefunden werden muss.

(1) wird u.a. unterstützt durch den 1TBS-Stil (öffnende geschweifte
Klammer am Ende des Funktions- oder Kontrollstrukturkopfs) und durch den
Verzicht auf redundante Klammern (wenn der Rumpf einer Kontrollstruktur
nur aus einer einzelnen Anweisung besteht).

(2) wird erreicht durch Umbrüche an logisch sinnvollen Stellen oder
Aufteilung von langen Anweisungen in mehrere Einzelanweisungen.

(4) wird durch Einrückungen erreicht und impliziert damit, dass Kopf und
Rumpf von Kontrollstrukturen in getrennten Zeilen stehen sollten.

Ich sehe keine Vorteile des Allman-Stils (öffnende geschweifte Klammer
in einer eigenen Zeile) gegenüber dem 1TBS-Stil. Für die Lesbarkeit ist
IMHO die Position der öffnenden Klammer völlig unwichtig. Wichtiger ist,
dass die schließende Klammer zum einleitenden Schlüsselwort (if, for,
while, do, try) ausgerichtet ist.

Was die Navigation innerhalb des Codes mittels Klammerpaarung betrifft:
Diese funktioniert auch beim 1TBS-Stil. Wenn man als Programmierer aber
(wie eingangs erwähnt) eher einrückungsorientiert arbeitet, wünscht man
sich auch eine einrückungsorientierte Navigation. Diese wird leider
nicht von allen IDEs und Editoren unterstützt, kann aber oft durch ein
Plugin nachgerüstet werden, wie bspw. diesem hier für Vim:

  https://github.com/jeetsukumaran/vim-indentwise

Damit kann man unabhängig von den Klammern bspw. an den Anfang oder das
Ende des aktuellen Blocks oder in den übergeordneten Block springen.

Die einrückungsorientierte Navigation hat zudem den Vorteil, dass sie
auch für blockklammerlose Programmiersprachen wie bspw. Python oder
Haskell funktioniert.

[Andreas B. (bitverdreher)]

Yalu X. schrieb:
> der
> Programmierer orientiert sich bevorzugt an den Einrückungen.
Da stimme ich Dir zu. Andere sehen das anders. HildeK findet das z.B. 
unleserlich.

> Es sollte möglichst viel Code auf einmal im Editorfenster sichtbar
>    sein (aber nicht um jeden Preis).
Und genau hier hapert es ja an der Definition: Was ist jeder Preis? Das 
sieht jeder eben etwas anders.

Fazit: Dieser Thread hat das Potential, die 1000er Marke zu 
überschreiten. ;-)

[Einer K. (Gast)]

Yalu X. schrieb:
> wird durch Einrückungen erreicht
> .....
> Ich sehe keine Vorteile des Allman-Stils (öffnende geschweifte Klammer
> in einer eigenen Zeile) gegenüber dem 1TBS-Stil. Für die Lesbarkeit ist
> IMHO die Position der öffnenden Klammer völlig unwichtig. Wichtiger ist,
> dass die schließende Klammer zum einleitenden Schlüsselwort (if, for,
> while, do, try) ausgerichtet ist.

Einrückungen sind für C/C++ Kompiler völlig Irrelevant.
Blockklammern nicht.

Der Allman Stil bringt beides zueinander.
Es ist auf den ersten Blick zu erkennen, beim überfliegen des Codes, ob 
diese beiden "symmetrisch" sind.
"Schöner Code" bietet diese Symmetrie.
Wenn irgedwas messy ist, fällt das sofort auf.

Mein "Auge" erwartet diese Symmetrie.

OK, ist eine Frage der Gewöhnung.
Ich kann auch den 1TBS-Stil lesen.
Ist aber deutlich aufwändiger zu erkennen (für mich), ob die Klammern 
richtig gesetzt sind, oder die Einrückung stimmt.

[Andreas B. (bitverdreher)]

Arduino Fanboy D. schrieb:
> Einrückungen sind für C/C++ Kompiler völlig Irrelevant.
> Blockklammern nicht.

Daher sind die Einrückungen auch für den Programmierer und die Klammern 
für den Kompiler gedacht.
Ich sehe das genauso wie Yalu X.: Man sieht bei 1TBS auf einem Blick 
(ohne etwas lesen zu müssen) die Struktur des Programms. Und das auch 
auf einen  nicht-32" Monitor.

[Einer K. (Gast)]

Andreas B. schrieb:
> Daher sind die Einrückungen auch für den Programmierer und die Klammern
> für den Kompiler gedacht.
Richtig!
Und doch handeln sie das gleiche Thema ab.

Ein anderes Wort für Symmetrie ist "Kunst für doofe".
Vielleicht ist das der Grund, warum mir der Allman Stil eher liegt.

[HildeK (Gast)]

Andreas B. schrieb:
> HildeK findet das z.B. unleserlich.
Ich schrieb 'fast unleserlich' und das war schon etwas übertrieben 
ausgedrückt.
Jedenfalls ist es für mich trotz Einrückung nicht ganz so leicht als 
Block erkennbar wie beim Allman-Stil (Begriff gerade neu gelernt ?). Das 
ist auch einer der Gründe, warum ich um Python einen Bogen mache. Vor 
allem dann, wenn die Blöcke noch geschachtelt sind. Das Einrücken 
verwende ich trotzdem, mit wenigen Ausnahmen: kleine, temporäre 
Anweisungen für Kontrollausgaben während der Entwicklung schreibe ich 
einfach linksbündig. Das erleichtert das Bereinigen, wenn der Code läuft 
und würde bei Python nicht gehen.

Die von Yalu X. genannten Kriterien sind auch für mich wichtig mit 
Priorität auf (4), die schnelle Erkennbarkeit. (1) ist für mich am 
wenigsten wichtig - meine Progrämmchen sind eher klein.

Eigentlich sollte ich mich als Hobby-Gelegenheits-Programmierer hier in 
dem Thread gar nicht melden ... ?

[Frank M. (ukw) (Moderator)]

Rolf M. schrieb:
> Ich mache auch keine Klammern, aber nur dann, wenn es sowohl im if-, als
> auch (sofern vorhanden) im else-Teil jeweils nur genau eine Zeile gibt.

Und wie oft musstest Du die Klammern nach Codeänderungen nachträglich 
wieder hinzufügen? Von daher habe ich mir das (gefährliche) Spielchen 
ohne Klammern schon in den 80ern abgewöhnt.

Hier noch ein böses, aber reales Beispiel - (Gosling Emacs, aus dem 
Gedächtnis wiedergegeben):

In irgendeiner tief versteckten H-Datei:

#define wrapline() if (col > cols) wrapit (currentline)  // für die Einzeilen-if-Schreiber ;-)

In der C-Datei:

    if (linetoolong)
        wrapline ();
    else
        do_something_other ();

Man sollte kurz mal nachdenken, auf welches if sich das else bezieht - 
gerade wenn sich solche vermeintlichen Funktionen, die man aus einer 
fremden Lib anwendet, dann im Debugger tatsächlich als Makro entpuppen. 
Ich jedenfalls schaue nicht jedesmal in den Code der Lib, wenn ich eine 
vermeintliche Funktion daraus aufrufe.

Bei

    if (linetoolong)
    {
        wrapline ();
    }
    else
    {
        do_something_other ();
    }

läufts dann richtig.

Klar, das Makro ist einfach schlecht gemacht, um nicht zu sagen 
"fehlerhaft umgesetzt", aber gerade dann, wenn man nicht selbst 
programmierte Libs anwendet, schadet es nicht, von vornherein defensiv 
an die Sache heranzugehen.

[Einer K. (Gast)]

Eine Randbemerkung für die Arduino Jünger:
Man hat mit der Arduino IDE ein weites Spektrum an an Möglichkeiten die 
automatische Formatierung, damit auch schon bei der Eingabe, zu 
beeinflussen.
Es wird intern dieses Tool genutzt:
http://astyle.sourceforge.net/astyle.html

Die IDE Vorgaben finden sich in einer Konfigurationsdatei:
{Arduino IDE installation folder}/lib/formatter.conf
(neustart der IDE notwendig)

Beispiel;
Ein hinzufügen der Zeile
> style=allman
stellt von 1TBS auf Allman um

[Benedikt M. (bmuessig)]

Rolf M. schrieb:
> Für dich vielleicht. Ich hatte damit in >25 Jahren C- und
> C++-Programmierung nie ein Problem.

Bei mir sind's zwar nur 6 Jahre C, aber ich kann mich dem nur 
anschließen. Ein Problem mit den weggelassenen Klammern hatte ich bisher 
noch keines.


Frank M. schrieb:
> #define wrapline() if (col > cols) wrapit (currentline)  // für die
> Einzeilen-if-Schreiber ;-)

So etwas macht man in Header-Dateien nicht!
Viele Entwickler verkapseln solche Header-Makros in einer do 
while(false), oder fügen die Klammen in das Makro ein.

[Frank M. (ukw) (Moderator)]

Benedikt M. schrieb:
> Frank M. schrieb:
> #define wrapline() if (col > cols) wrapit (currentline)  // für die
> Einzeilen-if-Schreiber ;-)
>
> So etwas macht man in Header-Dateien nicht!
> Viele Entwickler verkapseln solche Header-Makros in einer do
> while(false), oder fügen die Klammen in das Makro ein.

Ich habe doch oben geschrieben, dass das Makro fehlerhaft programmiert 
wurde, lies nochmal nach.

Korrekt wäre gewesen:

#define wrapline() do { if (col > cols) wrapit (currentline); } while (0)

Aber egal wie Du es drehst oder wendest: Du musst geschweifte Klammern 
einsetzen, damit es richtig läuft. Klar macht man das grundsätzlich im 
Makro, aber dem Compiler ist das egal: Fehler ist Fehler. Und ich 
empfinde es letztlich als inkonsequent, im Makro Klammern vorzuschreiben 
und im Code nicht. Von daher halte ich mich da konsequent an die 
Schreibweise mit Klammern - egal ob Makro oder C-Code.

Zum obigen "bösen" Beispiel:

Schuld an dem oben geschilderten Fehler war damals übrigens ein 
"C-Beautifier", der eingesetzt wurde, um den Gosling-Code, der für BSD 
geschrieben wurde, auf UNIX System-V zu portieren. Eigentlich sollte der 
Beautifier nur zu lange Symbolnamen kürzen, da der System-V-Compiler da 
damals eine Längenbeschränkung hatte. Als Nebeneffekt hat er aber auch 
gewschweifte Klammern rausgeschmissen, wo er sie für "überflüssig" 
betrachtete.

Ergebnis: Gosling-Emacs konnte in den ersten System-V-Versionen keine 
langen Zeilen umbrechen.

[Andreas B. (bitverdreher)]

Frank M. schrieb:
> Als Nebeneffekt hat er aber auch
> gewschweifte Klammern rausgeschmissen, wo er sie für "überflüssig"
> betrachtete.

Auch die, die Du vorher mühevoll reingeschrieben hattest?
Den Ersteller dieses "C-Beautifier" würde ich erschießen.

Aber ich sehe schon, wenn man mit solchen dirty Programmen rechnen muß, 
sollte man wirklich immer die Klammer verwenden.
Mir ist so etwas jedenfalls noch nicht untergekommen.

[Johannes S. (Gast)]

Es gibt aber zB debug Makros die den Programmfluss bei if ohne 
geschweifte Klammern verändern können. Bin ich auch mal drauf 
reingefallen, ist unschön weil man das Makro ja an anderer Stelle 
ändert.
AStyle und Editor der Klammern sofort setzt und fertig.
Obwohl... damit habe ich auch mal ein printf(„%d“);value
produziert. Ist auch gültiger C Code, gibt nur ne Warnung.

[Tim T. (tim_taylor)]

Frank M. schrieb:
> Man sollte kurz mal nachdenken, auf welches if sich das else bezieht -
> gerade wenn sich solche vermeintlichen Funktionen, die man aus einer
> fremden Lib anwendet, dann im Debugger tatsächlich als Makro entpuppen.
> Ich jedenfalls schaue nicht jedesmal in den Code der Lib, wenn ich eine
> vermeintliche Funktion daraus aufrufe.
>
> Bei
>

>     if (linetoolong)
>     {
>         wrapline ();
>     }
>     else
>     {
>         do_something_other ();
>     }
>

>

Aus genau diesem Grund pack ich auch bei Einzelanweisungen diese immer 
in einen (einzeiligen) Klammerblock:

if (linetoolong) { wrapline (); }
else { do_something_other (); }

Hat den Vorteil das selbst Schweinereien mit dem Präprozessor 
unschädlich bleiben aber nicht ganz so viel vertikaler Platz 
verschwendet wird.

Dementsprechend setze ich die Klammern auch sonst immer asymmetrisch, 
also eigentlich 1TBS Stil, jedoch ist das else bei mir auf gleicher 
Ebene wie das zugehörige if. Aus Interesse, heißt denn dieser Stil?

if (blub) {
 foo();
 bar();
}
else {
 bar();
 foo();
}

Ich muss jedoch zugeben dass der Allman Stil am übersichtlichsten ist. 
Ich benutze den selber (aus Faulheit) im Visual Studio, nur eben der 
vertikale Platzverbrauch ist enorm.

[Einer K. (Gast)]

Andreas B. schrieb:
> Aber ich sehe schon, wenn man mit solchen dirty Programmen rechnen muß,
> sollte man wirklich immer die Klammer verwenden.
Man sollte sich auch nicht auf die Einrückungen verlassen.
(wenn sie denn Menschen gemacht sind)
Auch schlägt da das Kuddelmuddel mit Space und Tab Einrückungen zu.
Ins Besondere bei Fremdcode.

---

Wenn ich Code in den Editor hacke, interessieren mich Leerzeichen, Tabs 
und Einrückungen nur bedingt. Ein ungestörter Schreibfluss ist mir viel 
wichtiger.

Wenn der Teilbereich abgeschlossen ist, ein Druck auf Autoformatierung, 
und ich kann an dem symmetrischen Bild sofort sehen, ob ich Mist mit der 
Struktur gebaut habe, und dann korrigieren.

[Frank M. (ukw) (Moderator)]

Andreas B. schrieb:
> Auch die, die Du vorher mühevoll reingeschrieben hattest?

Gosling Emacs stammt von Gosling, nicht von mir ;-)

Ich hatte damals (Mitte der 80er) lediglich die Aufgabe, diesen auf 
System-V zu portieren.

> Den Ersteller dieses "C-Beautifier" würde ich erschießen.

Wenns hilft ;-) Wenn ich es recht in Erinnerung habe, war das damals ein 
BSD-Tool. Kann mich aber auch irren und es gehörte zu System-V.

> Aber ich sehe schon, wenn man mit solchen dirty Programmen rechnen muß,
> sollte man wirklich immer die Klammer verwenden.

Es gibt da ein nettes Buch, nämlich das "C Puzzle Book". Das Ding 
behandelt alle nur erdenklichen Stolperfallen, in die man so tappen 
kann. Die Lektüre macht übrigens viel Spaß.

Hier zum Beispiel:

#include <stdio.h>
#define NEG(a) -a

int main ()
{
    int x = 3;

    printf ("negative value of -3 is %d\n", NEG(-x));
    return 0;
}

Übersetzt und ausgeführt:

cc neg.c -o neg && ./neg
negative value of -3 is 3

Viele C-Compiler haben da noch vor ein paar Jahren folgendes ausgegeben:

negative value of -3 is 2

Der gcc kennt da auch noch eine "abwärtskompatible" Option, leider ist 
mir diese entfallen, um das noch zu reproduzieren.

[Teo D. (teoderix)]

[wurscht wer]
> Ja, nehme ich zur Kenntnis. Normalerweise würde es aber so aussehen:
>   if (bla)
>   {
>      a=5;
>      b=3;
>   }
>   else
>   {
>      a=0;
>      b=1;
>   }

Ich bevorzuge da eher:

 if (bla) {
        a=5;
        b=3;
   } else {
        a=0;
        b=1;
   }

[Andreas B. (bitverdreher)]

Frank M. schrieb:
> int main ()
> {
>     int x = 3;
>
>     printf ("negative value of -3 is %d\n", NEG(-x));
>     return 0;
> }
>
> Übersetzt und ausgeführt:cc -Wtraditional neg.c -o neg && ./neg
> negative value of -3 is 3

Würde ich auch sagen. Neg von -3 is 3. ;-)
Oder war das anders gemeint? (Die Funktion NEG() kenne ich nicht. oder 
ist das auch so ein dirty Makro?)

[Jörg W. (dl8dtl) (Moderator)]

Andreas B. schrieb:
> Die Funktion NEG() kenne ich nicht. oder ist das auch so ein dirty
> Makro?

Stand doch drüber. Ein Makro, bei dem das Argument auf der rechten Seite 
nicht geklammert ist. Was zur Folge hat, dass er sowas wie "--x" 
substituiert.

[Andreas B. (bitverdreher)]

Jörg W. schrieb:
> Stand doch drüber.

Stimmt, das habe ich übersehen.

> Was zur Folge hat, dass er sowas wie "--x"
> substituiert.
Aber so stimmt das doch. Das würde ich spontan auch so erwarten. - zu -3 
gibt +3.

[Jörg W. (dl8dtl) (Moderator)]

Andreas B. schrieb:
> - zu -3 gibt +3.

Korrekt. Aber --x ist ja ein pre-Dekrement. :^o

Wenn man das Makro-Argument klammert, hat man -(-x), das ist eindeutig.

[Andreas B. (bitverdreher)]

ahh, ok, jetzt habe ich verstanden wie das gemeint war. Ich habe immer 
nur die Rechenoperation an sich im Blickfeld gehabt.

Ich sollte mir das "C Puzzle Book" mal reinziehen. ;-)

[zitter_ned_aso (Gast)]

aber warum macht(e) der Compiler 2 daraus?

durcht die Substituion würde doch da --3 stehen. Und das wäre ein 
R-Value, das man nicht inkrementieren/dekrementieren darf. Also würde 
ich da eine Fehlermeldng erwarten. (oder meinetwegen die zweifache 
Negation) Aber doch keine 2.

[Jörg W. (dl8dtl) (Moderator)]

zitter_ned_aso schrieb:
> durcht die Substituion würde doch da --3

Nein, es steht --x. x ist ja eine Variable.

[Jobst Q. (joquis)]

Teo D. schrieb:
> Ich bevorzuge da eher: if (bla) {
>         a=5;
>         b=3;
>    } else {
>         a=0;
>         b=1;
>    }

Ich mag es am liebsten so:
if (bla){
  a=5;
  b=3;
  }
else {
  a=0;
  b=1;
  }
sonstwas();

Damit ist klar, dass 'else' auf derselben Ebene ist wie das 'if' und 
'sonstwas()'. Keine einsamen schließenden Klammern, sie gehören zum 
Block, der geschlossen wird.

Wie ich eben gerade herausgefunden habe, nennt er sich auch Ratliff-Stil
https://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#Ratliff_Stil

[zitter_ned_aso (Gast)]

ja, die Option "gcc -E"  zeigte es.

Aber er macht "- -x" daraus. Mit einem Leerzeichen dazwischen. Also 
gleich als Vorzeichenwechsel.

[Frank M. (ukw) (Moderator)]

zitter_ned_aso schrieb:
> Aber er macht "- -x" daraus. Mit einem Leerzeichen dazwischen. Also
> gleich als Vorzeichenwechsel.

Ja, mittlerweile. Vor ein paar Jahren machten alle mir bekannten 
C-Preprocessoren noch ein "--x" daraus, also ohne das Leerzeichen. Und 
so lieferte NEG(-x) das Ergebnis "2" und dekrementierte obendrein noch 
die Variable x. Die Compilerbauer haben mittlerweile dazugelernt. ;-)

Hier kann man das ursprüngliche Verhalten mit gcc noch nachvollziehen:

gcc -traditional-cpp -E n.c

Ergebnis:

# 1 "n.c"
# 1 "<command-line>"
# 1 "n.c"

int main ()
{
    int x = 3;

    printf ("negative value of -3 is %d\n", --x);
    return 0;
}

x wird also dekrementiert und dann das Ergebnis 2 ausgegeben.

Allerdings muss man vorher das include von stdio.h rauswerfen, sonst 
weigert sich der Compiler wegen Inkompatibilität von stdio.h:

"You need a ISO C conforming compiler to use the glibc headers"

P.S.
Stichwort für weitere Recherche ist hier "Token Spacing"

[Jörg W. (dl8dtl) (Moderator)]

Frank M. schrieb:
> Die Compilerbauer haben mittlerweile dazugelernt. ;-)

Vermutlich haben auch die Standardisierer dazu gelernt.

[HildeK (Gast)]

Jobst Q. schrieb:
> Wie ich eben gerade herausgefunden habe, nennt er sich auch Ratliff-Stil
> https://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#Ratliff_Stil

Oh, da gibt es ja noch jede Menge benannte Varianten.
Wenn schon eine Alternative zum Zeilen sparen, dann würde mir der 
Horstmann-Stil auch noch zusagen.
Und der Ratliff-Stil ist (für mich) jedenfalls lesbarer als der 1TBS ...

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
> Frank M. schrieb:
> Die Compilerbauer haben mittlerweile dazugelernt. ;-)
>
> Vermutlich haben auch die Standardisierer dazu gelernt.

Das trifft es vermutlich besser.

[Oliver S. (oliverso)]

Um die Diskussion mal etwas vorranzubringen, und Einigkeit zuu erzeugen:

Whitesmiths

Klammern in eigener Zeile, aber um eine halbe Einrückung zum Text 
versetzt. Da muß man wohl bewusstseinserweiternde Substanzen rauchen, um 
das gut zu finden.

Aus den Eclipse-Formatierungsbeispielen mal ein C++-Lamda:

int foo()
    {
    auto f =
      []()
    {for(int c1 = 0; c1 < 3; c1 ++)
        {
        for(int i = 0; i < 5; i ++)
      {
      for(int c2 = 0; c2 < 3; c2 ++)
          {
          }
      }
        }};
    }

Leider verkennt die Forensoftware die eigentliche Schönheit dieser 
Formatierung ;)

Oliver

[Jörg W. (dl8dtl) (Moderator)]

Oliver S. schrieb:
> Einigkeit zuu erzeugen

Das ist bei derartigen Fragen praktisch komplett unmöglich.

Ich habe schon in so vielen verschiedenen Umgebungen gearbeitet, das 
wichtigste generell ist: be consistent. Wenn du für jemanden arbeitest, 
der irgendeinen Coding style gesetzt hat, halte dich an ihn - egal, ob 
das nun der Brötchengeber ist oder irgendein größeres 
Opensource-Projekt, dem du zuarbeitest. Wenn du Code anderer 
modifizierst oder ergänzt (bspw. von Opensource-Projekten), halte dich 
an deren existierenden Stil, statt zu versuchen, ihnen deine 
Vorzugsvariante aufzudrängen.

Benutzen einen Editor/IDE, der flexibel genug ist, dass du ihn 
dahingehend passend konfigurieren kannst, dass er dir einen möglichst 
großen Teil dieser stilistischen Dinge abnimmt, sodass du dich auf deine 
eigentliche Arbeit konzentrieren kannst.

[zitter_ned_aso (Gast)]

boah, ist das häss.... schwer zu lesen.

aber zumindest werden die Whitespaces benutzt. Leider falsch ;-)

Wer schreibt denn sowas?

c ++;

[Einer K. (Gast)]

Dafür:
Oliver S. schrieb:
> }};
Eine Woche auf einer Streckbank der eigenen Wahl.

[Rolf M. (rmagnus)]

Yalu X. schrieb:
> Wichtigste Kriterien für gute Übersichtlichkeit und Lesbarkeit:
>
> 1. Es sollte möglichst viel Code auf einmal im Editorfenster sichtbar
>    sein (aber nicht um jeden Preis).

Das hat für mich eher geringe Priorität.

> 2. Die Zeilenlänge sollte auf ca. 80 bis 120 Zeichen beschränkt sein,
>    auch wenn der Bildschirm wesentlich mehr hergibt.

Habe ich früher auch gemacht, aber da Bildschirme heute eigentlich immer 
erheblich mehr hergeben und Namen z.B. von Funktionen gerne mal lang 
werden, halte ich eine Beschränkung auf 80 Zeichen auf jeden Fall für zu 
kurz, vor allem auch in C++ mit Namespaces und Enums. Da wird's ziemlich 
schnell ziemlich lang. Dann muss man Funktionsaufrufe schon ziemlich oft 
auf mehrere Zeilen verteilen, und die Sache wird dadurch dann zu 
unübersichtlich.

> 3. Längere Codeabschnitte sollten mittels Leerzeilen logisch gruppiert
>    werden.

Ja, das sehe ich auch so.

> 4. Besonderheiten im Kontrollfluss (Verzweigungen und Schleifen) sollten
>    auch beim schnellen Überfliegen auffallen, ohne dass man explizit
>    nach den zugehörigen Schlüsselwörtern Ausschau halten muss.

Ja. Wobei sie das meist schon durch Syntax-Highlighting tun.

> Ich sehe keine Vorteile des Allman-Stils (öffnende geschweifte Klammer
> in einer eigenen Zeile) gegenüber dem 1TBS-Stil. Für die Lesbarkeit ist
> IMHO die Position der öffnenden Klammer völlig unwichtig. Wichtiger ist,
> dass die schließende Klammer zum einleitenden Schlüsselwort (if, for,
> while, do, try) ausgerichtet ist.

Da sind wir eben unterschiedlicher Meinung. Für mich muss sie auch zur 
öffnenden Klammer ausgerichtet sein. Warum die Ausrichtung der 
schießenden Klammer wichtig ist, die der öffnenden aber nicht, 
erschließt sich mir nicht.

Andreas B. schrieb:
> Arduino Fanboy D. schrieb:
>> Einrückungen sind für C/C++ Kompiler völlig Irrelevant.
>> Blockklammern nicht.
>
> Daher sind die Einrückungen auch für den Programmierer und die Klammern
> für den Kompiler gedacht.

Dennoch obliegt die Aufgabe der Sicherstellung, dass beides 
zusammenpasst, dem Programmierer. Er sollte das möglichst auf einen 
Blick erkennen können. Und wenn ich von einer öffnenden Klammer aus 
einfach senkrecht nach unten bis zur entsprechenden Gegenklammer suchen 
muss, finde ich das sehr übersichtlich. Oder wenn ich von der 
schließenden nach oben einfach nach dem genauso, nur spiegelverkehrt 
aussehendem Gegenstück suche. Mein Pattern-Matching funktioniert da 
schneller, als wenn ich stattdessen je nach Fall nach einem if, while 
oder for suchen muss.

HildeK schrieb:
> Andreas B. schrieb:
>> HildeK findet das z.B. unleserlich.
> Ich schrieb 'fast unleserlich' und das war schon etwas übertrieben
> ausgedrückt.
> Jedenfalls ist es für mich trotz Einrückung nicht ganz so leicht als
> Block erkennbar wie beim Allman-Stil (Begriff gerade neu gelernt ?).
> Das
> ist auch einer der Gründe, warum ich um Python einen Bogen mache.

Das ist gerade das, was ich an Python besonders schön finde. Es gibt 
diese Diskrepanz zwischen dem, was dem Programmierer als erstes in Auge 
sticht (die Einrückung) und dem, wonach der Compiler geht (die Klammern) 
einfach nicht. Als Bonus muss man sich auch keine Gedanken machen, wohin 
man jetzt die Klammern schreibt. :)

> Vor allem dann, wenn die Blöcke noch geschachtelt sind. Das Einrücken
> verwende ich trotzdem, mit wenigen Ausnahmen: kleine, temporäre
> Anweisungen für Kontrollausgaben während der Entwicklung schreibe ich
> einfach linksbündig. Das erleichtert das Bereinigen, wenn der Code läuft
> und würde bei Python nicht gehen.

Da hast du allerdings recht. Das hat mich tatsächlich auch schon mal 
gestört.

Frank M. schrieb:
> Rolf M. schrieb:
>> Ich mache auch keine Klammern, aber nur dann, wenn es sowohl im if-, als
>> auch (sofern vorhanden) im else-Teil jeweils nur genau eine Zeile gibt.
>
> Und wie oft musstest Du die Klammern nach Codeänderungen nachträglich
> wieder hinzufügen?

Das würde ich mit "gelegentlich" kategorisieren.

Andreas B. schrieb:
> Frank M. schrieb:
>> Als Nebeneffekt hat er aber auch
>> gewschweifte Klammern rausgeschmissen, wo er sie für "überflüssig"
>> betrachtete.
>
> Auch die, die Du vorher mühevoll reingeschrieben hattest?
> Den Ersteller dieses "C-Beautifier" würde ich erschießen.

Der Beautifier kann doch nix dafür, wenn da jemand mit viel Mühe 
kunstvoll unnötige Klammern reinmalt. :)
Ggf. muss man dem Beautifier auch einfach sagen, was man für "beautiful" 
erachtet.

Arduino Fanboy D. schrieb:
> Wenn der Teilbereich abgeschlossen ist, ein Druck auf Autoformatierung,
> und ich kann an dem symmetrischen Bild sofort sehen, ob ich Mist mit der
> Struktur gebaut habe, und dann korrigieren.

Die Autoformatierung passiert bei mir schon während des Tippens. Ich 
erkenne bereits beim Einfügen einer schließenden Klammer, dass was nicht 
passt, wenn sie auf der falschen Einrückungsebene erscheint.

Jörg W. schrieb:
> Frank M. schrieb:
>> Die Compilerbauer haben mittlerweile dazugelernt. ;-)
>
> Vermutlich haben auch die Standardisierer dazu gelernt.

Ich glaube, das war in Standard-C schon immer falsch.

zitter_ned_aso schrieb:
> Wer schreibt denn sowas?
> c ++;

Oder sowas:

{for(int c1

[HildeK (Gast)]

Rolf M. schrieb:
> Das ist gerade das, was ich an Python besonders schön finde. Es gibt
> diese Diskrepanz zwischen dem, was dem Programmierer als erstes in Auge
> sticht (die Einrückung) und dem, wonach der Compiler geht (die Klammern)
> einfach nicht. Als Bonus muss man sich auch keine Gedanken machen, wohin
> man jetzt die Klammern schreibt. :)

Aber ein Leerzeichen an der falschen Stelle und schon macht Python was 
anderes als ich eigentlich wollte. Das kann bei längeren Sequenzen schon 
mal passieren. Und das Peilen, ob alles richtig eingerückt ist, gerade 
über mehr als eine Bildschirmseite hinweg, macht es nicht einfacher.
Dann lieber die Klammer, imho.

[Yalu X. (yalu) (Moderator)]

Rolf M. schrieb:
>> Ich sehe keine Vorteile des Allman-Stils (öffnende geschweifte Klammer
>> in einer eigenen Zeile) gegenüber dem 1TBS-Stil. Für die Lesbarkeit ist
>> IMHO die Position der öffnenden Klammer völlig unwichtig. Wichtiger ist,
>> dass die schließende Klammer zum einleitenden Schlüsselwort (if, for,
>> while, do, try) ausgerichtet ist.
>
> Da sind wir eben unterschiedlicher Meinung. Für mich muss sie auch zur
> öffnenden Klammer ausgerichtet sein. Warum die Ausrichtung der
> schießenden Klammer wichtig ist, die der öffnenden aber nicht,
> erschließt sich mir nicht.

Das ist kein absolutes Muss, aber IMHO ganz praktisch, um schnell den
Anfang und das Ende einer If-Anweisung zu erkennen: Den Anfang bildet
das Schlüsselwort "if", das Ende die schließende Klammer, und genau
diese beiden sollten deswegen leicht als zusammengehörig erkannt werden.
Die öffnende Klammer muss zwar aus syntaktischen Gründen vorhanden sein,
trägt aber für mich zur Lesbarkeit des Codes nichts bei. Deswegen ist es
auch ziemlich egal, ob man sie an eine exponierte Position setzt (wie im
Allman-Stil) oder eher versteckt (wie im 1TBS-Stil).

In vielen Basic-Dialekten, Fortran und VHDL wird das übrigens ganz
ähnlich gemacht, nur dass dort an die Stelle der geschweiften Klammern
die Schlüsselwörter "then" und "end if" treten:

if condition then
  ...
end if

Und bevor jetzt folgender Vorschlag kommt:

#define then {
#define else } else {
#define endif }

Nein, so weit würde ich nicht gehen :)

[Stefan F. (Gast)]

HildeK schrieb:
> Und das Peilen, ob alles richtig eingerückt ist, gerade
> über mehr als eine Bildschirmseite hinweg, macht es nicht einfacher.

Wobei die Python Macher dazu argumentieren, dass solcher Code ohnehin in 
kleinere Funktionen zerlegt werden sollte.

Ich benutze in Java Programmen manchmal absichtlich zusätzliche 
Klammer-Blöcke um den Code zu strukturieren. Ein typischer Fall:

void tuwas(User user)
{
    CreateUserRequest r=new CreateUserRequest();
    {
        r.setFirstName(user.getFirstName());
        r.setLastName(user.getLastName());
        r.setBirthDate(user.getBirthDate());

        Address a=new Address();
        {
            a.setStreet(user.getStreet());
            a.setHouseNumber(user.getHouseNumber());
            a.setZipCode(user.getZipCode();
            a.setCity(user.getCity());
            a.setCountry("Germany");
        }
        r.setAddress(a);
    }
    createUserImpl.invoke(r);
}

Ich weiß, es gibt elegantere Alternativen. Aber so sieht es auch schon 
wesentlich übersichtlicher aus, als ohne die Klammern.

[Jobst Q. (joquis)]

Yalu X. schrieb:
> Deswegen ist es
> auch ziemlich egal, ob man sie an eine exponierte Position setzt (wie im
> Allman-Stil) oder eher versteckt (wie im 1TBS-Stil).

Was ist daran versteckt? Das Ende einer Zeile ist auch eine exponierte 
Position. Dass zu einer öffnenden Klammer am Zeilenende eine Einrückung 
der nächsten Zeile gehört, ist leicht erkennbar und spart Platz.

Der schließenden Klammer eine eigene Zeile zu lassen hat den praktischen 
Grund im Einfügen von weiteren Zeilen in den Block.

[Einer K. (Gast)]

Jobst Q. schrieb:
> Was ist daran versteckt?
Finde ich auch.... heimlich hinten dran gehangen.
So weit von der Einrückung entfernt, wie es geht.

Der Allman Stil stellt die Klammer weit mehr in den Vordergrund.
In klarem und sofort sichtbaren Zusammenhang mit der Einrückung.

Bedenke:
Einrückungen gibt es auch ohne Klammer.

Aber ok, kostet eine Zeile.
Wem der Preis zu hoch ist, ok... dann ist das so.
Meinen Segen.

[Johannes S. (Gast)]

VSCode macht es richtig schön finde ich. Es werden senkrechte Linien 
eingeblendet, dabei ist die zum zugehörigen Block heller dargestellt 
(beim dunklen Theme).

[Jobst Q. (joquis)]

Arduino Fanboy D. schrieb:
> Finde ich auch.... heimlich hinten dran gehangen.
> So weit von der Einrückung entfernt, wie es geht.

Das letzte Zeichen einer Zeile ist ja soo schwer zu finden.

[Einer K. (Gast)]

Jobst Q. schrieb:
> Das letzte Zeichen einer Zeile ist ja soo schwer zu finden.

Ja, je tiefer verschachtelt, desto weniger offensichtlich zuzuordnen.

Wie auch immer, wer meint das muss so, ok.
Aber für mich ist das nix.
Merke ich jedes mal, wenn ich sowas vor mir habe.

[Teo D. (teoderix)]

Jobst Q. schrieb:
> Das letzte Zeichen einer Zeile ist ja soo schwer zu finden.

Das is halt wie beim Lesen lernen. Der Eine buchstabiert noch, der 
Andere erfaßt komplette Seiten....

[Einer K. (Gast)]

Ja, das ist natürlich sehr wichtig, dass man in solchen 
Geschmacksfragen, jeden für doof erklärt, der es lieber anders mag.

Das festigt die eigene Position ungemein.
Nicht wahr?
Zeugt auch von weit überlegender Intelligenz, nehme ich mal an.

[zitter_ned_aso (Gast)]

Ich staune wie manche es fleißig überall Leerzeichen verwenden.

Bei Zuweisungen, bei binären Operatoren, und, und, und. Ein Leercheichen 
vor dem "="-Zeichen, ein Leerzeichen nach dem "="-Zeichen, ein 
Leerzeichen vor dem "+"-Zeichen, ... .

Mir würde der Daumen abfallen.

[Rolf M. (rmagnus)]

Jobst Q. schrieb:
> Yalu X. schrieb:
>> Deswegen ist es
>> auch ziemlich egal, ob man sie an eine exponierte Position setzt (wie im
>> Allman-Stil) oder eher versteckt (wie im 1TBS-Stil).
>
> Was ist daran versteckt? Das Ende einer Zeile ist auch eine exponierte
> Position. Dass zu einer öffnenden Klammer am Zeilenende eine Einrückung
> der nächsten Zeile gehört, ist leicht erkennbar und spart Platz.

Wenn ich aber nach Einrückung und Klammern suche, schaue ich nicht an 
das Ende der Zeile, sondern an den Anfang. Da ist es ärgerlich, wenn die 
öffnende Klammer da aus der Reihe tanzt und eben nicht da ist, wo alles 
andere zu finden ist, was die Strukturierung des Code zeigt.

zitter_ned_aso schrieb:
> Ich staune wie manche es fleißig überall Leerzeichen verwenden.

Und ich darüber, wie manche alles ohne Leerzeichen aufeinander klatschen 
können. So verschieden sind eben die Geschmäcker.

Arduino Fanboy D. schrieb:
> Ja, das ist natürlich sehr wichtig, dass man in solchen
> Geschmacksfragen, jeden für doof erklärt, der es lieber anders mag.

Wie schon gesagt: Bei manchen passt es nicht in ihr Weltbild, dass es 
auch andere Meinungen geben kann als die eigene. Wer eine andere Meinung 
hat, muss offensichtlich falsch liegen und dumm sein.

[Johannes S. (Gast)]

Es gibt nur zwei Meinungen: meine und die falsche. :)

[Andreas B. (bitverdreher)]

Arduino Fanboy D. schrieb:
> Ein anderes Wort für Symmetrie ist "Kunst für doofe".
> Vielleicht ist das der Grund, warum mir der Allman Stil eher liegt.

Arduino Fanboy D. schrieb:
> Ja, das ist natürlich sehr wichtig, dass man in solchen
> Geschmacksfragen, jeden für doof erklärt, der es lieber anders mag.

Hmmmm

[Frank M. (ukw) (Moderator)]

Yalu X. schrieb:
> Und bevor jetzt folgender Vorschlag kommt:#define then {
> #define else } else {
> #define endif }
>
> Nein, so weit würde ich nicht gehen :)

Stephen Bourne ging bei der Programmierung der Bourne-Shell sogar noch 
viel weiter:

Auszug aus 
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/mac.h :

#define IF  if(
#define THEN  ){
#define ELSE  } else {
#define ELIF  } else if (
#define FI  ;}

#define BEGIN  {
#define END  }
#define SWITCH  switch(
#define IN  ){
#define ENDSW  }
#define FOR  for(
#define WHILE  while(
#define DO  ){
#define OD  ;}
#define REP  do{
#define PER  }while(
#define DONE  );
#define LOOP  for(;;){
#define POOL  }

#define SKIP  ;
#define DIV  /
#define REM  %
#define NEQ  ^
#define ANDF  &&
#define ORF  ||

Beispiel der Funktion list():

LOCAL TREPTR  list(flg)
{
  REG TREPTR  r;
  REG INT    b;

  r = term(flg);
  WHILE r ANDF ((b=(wdval==ANDFSYM)) ORF wdval==ORFSYM)
  DO  r = makelist((b ? TAND : TORF), r, term(NLFLG));
  OD
  return(r);
}

Auch nett - string.c:

INT  cf(s1, s2)
  REG STRING s1, s2;
{
  WHILE *s1++ == *s2
  DO  IF *s2++==0
    THEN  return(0);
    FI
  OD
  return(*--s1 - *s2);
}

Oder - kurz und knackig - eine Null-Pointer-feste Variante von strlen():

INT  length(as)
  STRING as;
{
  REG STRING s;

  IF s=as THEN WHILE *s++ DONE FI
  return(s-as);
}

Bourne hat sich da sehr von Algol68 inspirieren lassen ;-)

Kompletter Source: 
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh

Erst 1984 mit der SVR2-Shell wurde sein Code "de-ALGOL68-ized", also von 
diesen kryptischen Makros befreit. Bis dahin sah der tatsächlich so aus 
;-)

Ist auf jeden Fall einen Blick wert, allerdings erinnert sein Code mehr 
an  IOCCC als an C.

[Chris D. (myfairtux) (Moderator)]

Interessanter Thread :-)

Ich gehöre auch zur "HildeK"-Fraktion: also schön die Klammern 
untereinander. Ich habe damals mal eine Umstellung versucht, aber ich 
konnte mich einfach nicht daran gewöhnen, also blieben die Klammern 
untereinander, auch wenn das eine Zeile kostet. Einfache Befehle setze 
ich ohne Klammern. Die Einrückung beträgt zwei Whitespace.

Glücklicherweise bin ich ja selbst Chef, mein MA hat damit allerdings 
auch kein Problem.

Wobei: ich kann mich nicht erinnern, jemals Fehler durch 
"Klammerprobleme" beim Compilieren gehabt zu haben.

Jörg W. schrieb:
> Benutzen einen Editor/IDE, der flexibel genug ist, dass du ihn
> dahingehend passend konfigurieren kannst, dass er dir einen möglichst
> großen Teil dieser stilistischen Dinge abnimmt, sodass du dich auf deine
> eigentliche Arbeit konzentrieren kannst.

Exakt. Man stellt das einmal so ein, wie man es haben möchte und muss 
dann nicht weiter darüber nachdenken.

[HildeK (Gast)]

Chris D. schrieb:
> "HildeK"-Fraktion

Nett ?, obwohl ich vermutlich der Einzige bin in dem Thread, der nur 
Hobby-Amateur-Gelegenheits-Softwerker ist ...

[Andreas B. (bitverdreher)]

HildeK schrieb:
> Nett ?, obwohl ich vermutlich der Einzige bin in dem Thread, der nur
> Hobby-Amateur-Gelegenheits-Softwerker ist ...

Nö, ich auch. Nach mir benennt aber niemand was. :-(

[HildeK (Gast)]

Andreas B. schrieb:
> Nö, ich auch. Nach mir benennt aber niemand was. :-(

Das tut mir unendlich leid für dich!
Was nicht ist, kann ja noch werden - es war auch bei mir Premiere heute 
...

[Jobst Q. (joquis)]

Stefan ⛄ F. schrieb:
> Ich benutze in Java Programmen manchmal absichtlich zusätzliche
> Klammer-Blöcke um den Code zu strukturieren. Ein typischer Fall:
> void tuwas(User user)
> {
>     CreateUserRequest r=new CreateUserRequest();
>     {
>         r.setFirstName(user.getFirstName());
>         r.setLastName(user.getLastName());
>         r.setBirthDate(user.getBirthDate());
>
>         Address a=new Address();
>         {
>             a.setStreet(user.getStreet());
>             a.setHouseNumber(user.getHouseNumber());
>             a.setZipCode(user.getZipCode();
>             a.setCity(user.getCity());
>             a.setCountry("Germany");
>         }
>         r.setAddress(a);
>     }
>     createUserImpl.invoke(r);
> }

Mich würde das eher irritieren. Denn bei Einrückungen erwarte ich, dass 
es Bedingungen gibt, unter denen der Code ausgeführt wird, was hier aber 
nicht der Fall ist. Dass die a.Zuweisungen innerhalb der r.Zuweisungen 
liegen, empfinde ich als unnötige Verschachtelung. Um sie voneinander 
abzusetzen, reichen auch einfache Leerzeilen.

void tuwas(User user){

Address a=new Address();
a.setStreet(user.getStreet());
a.setHouseNumber(user.getHouseNumber());
a.setZipCode(user.getZipCode();
a.setCity(user.getCity());
a.setCountry("Germany");

CreateUserRequest r=new CreateUserRequest();
r.setFirstName(user.getFirstName());
r.setLastName(user.getLastName());
r.setBirthDate(user.getBirthDate());
r.setAddress(a);

createUserImpl.invoke(r);
}

[Vincent H. (vinci)]

Jobst Q. schrieb:
> Mich würde das eher irritieren. Denn bei Einrückungen erwarte ich, dass
> es Bedingungen gibt, unter denen der Code ausgeführt wird, was hier aber
> nicht der Fall ist. Dass die a.Zuweisungen innerhalb der r.Zuweisungen
> liegen, empfinde ich als unnötige Verschachtelung. Um sie voneinander
> abzusetzen, reichen auch einfache Leerzeilen.

Dann solltest du dich übers Prinzip des Block Scopes schlauch machen. 
Das hat nämlich tatsächlich Einfluss auf den Code und ist nicht nur "für 
die Optik" gut...

[Jörg W. (dl8dtl) (Moderator)]

Vincent H. schrieb:
> Das hat nämlich tatsächlich Einfluss auf den Code und ist nicht nur "für
> die Optik" gut...

In erster Linie hat es syntaktischen Einfluss. Einen ordentlichen 
Compiler interessiert das ansonsten nicht.

Ich mache sowas bspw., wenn ich innerhalb eines case-Zweigs eine lokale 
Variable brauche. Sowas geht nicht:

switch (param) {
   // …
   case FOO: int i = 2 * param;
             do_something(i);
             break;

So geht es aber:

switch (param) {
   // …
   case FOO: {
             int i = 2 * param;
             do_something(i);
             break;
             }

[Oliver S. (oliverso)]

Jörg W. schrieb:
> Vincent H. schrieb:
>> Das hat nämlich tatsächlich Einfluss auf den Code und ist nicht nur "für
>> die Optik" gut...
>
> In erster Linie hat es syntaktischen Einfluss. Einen ordentlichen
> Compiler interessiert das ansonsten nicht.

Scope interessiert den Compiler, und sollte jeden Programierer ebenso 
interessieren. Da sind auch Blöcke ohne Bedingung sinnvoll.

Oliver

[Stefan F. (Gast)]

Jörg W. schrieb:
> So geht es aber:
> switch (param) {
>    // …
>    case FOO: {
>              int i = 2 * param;
>              do_something(i);
>              break;
>              }

Der break muss aber hinter die Klammer, denke ich.

[Jörg W. (dl8dtl) (Moderator)]

Oliver S. schrieb:
>> In erster Linie hat es syntaktischen Einfluss.

> Scope interessiert den Compiler

Schrieb ich doch: syntaktischen Einfluss.

Man kann damit den Scope der Variablen beschränken. Der Compiler 
interessiert sich aber jenseits dessen kaum dafür: für den ist die 
Lebenszeit einer Variablen praktisch in dem Moment zu Ende, wo ihr Wert 
nicht mehr benutzt wird - egal, ob das nun durch einen Scope explizit 
eingeschränkt wird oder einfach nur durch tatsächliche (Nicht-)Nutzung.

[Jörg W. (dl8dtl) (Moderator)]

Stefan ⛄ F. schrieb:
>> case FOO: {
>>              int i = 2 * param;
>>              do_something(i);
>>              break;
>>              }
>
> Der break muss aber hinter die Klammer, denke ich.

Nö, ist egal. Kann man davor schreiben oder dahinter. In jedem Falle ist 
an dieser Stelle der aktuelle case-Label zu Ende gearbeitet, und es 
folgt ein Sprung zum Ende der case-Anweisung.

[Oliver S. (oliverso)]

Jörg W. schrieb:
> für den ist die
> Lebenszeit einer Variablen praktisch in dem Moment zu Ende, wo ihr Wert
> nicht mehr benutzt wird - egal, ob das nun durch einen Scope explizit
> eingeschränkt wird oder einfach nur durch tatsächliche (Nicht-)Nutzung.

Man erkennt den C-Programmierer ;) Es soll ja gerüchteweise auch 
Programmiersprachen mit Destruktoren geben.

Aber auch in C ist ein genaues Wissen über die Lebenszeit einer 
Variablen mehr als nur hilfreich.

Oliver

[Jörg W. (dl8dtl) (Moderator)]

Oliver S. schrieb:
> Es soll ja gerüchteweise auch Programmiersprachen mit Destruktoren
> geben.

Auch für die dürfte nicht garantiert sein, dass sie just mit der 
schließenden geschweiften Klammer aufgerufen werden, sondern wohl nur, 
dass sie überhaupt irgendwann mal am Ende der Lebenszeit der Variablen 
gerufen werden. Aber da kenne ich mich in der Tat nicht so genau aus.

> Aber auch in C ist ein genaues Wissen über die Lebenszeit einer
> Variablen mehr als nur hilfreich.

Das ist unbestritten.

[Einer K. (Gast)]

Jörg W. schrieb:
> sondern wohl nur,
> dass sie überhaupt irgendwann mal am Ende der Lebenszeit der Variablen
> gerufen werden. Aber da kenne ich mich in der Tat nicht so genau aus.
Da scheiden sich die Geister.

Die einen machen es sich mit GC (Müllabfuhr), die anderen ohne.
C++ tuts in der Regel ohne GC.

[Oliver S. (oliverso)]

Jörg W. schrieb:
> Auch für die dürfte nicht garantiert sein, dass sie just mit der
> schließenden geschweiften Klammer aufgerufen werden, sondern wohl nur,
> dass sie überhaupt irgendwann mal am Ende der Lebenszeit der Variablen
> gerufen werden. Aber da kenne ich mich in der Tat nicht so genau aus.

In C++ ist garantiert, daß der Destruktor aufgerufen wird, wenn die 
Variable out of scope geht.

Oliver

[Vincent H. (vinci)]

Jörg W. schrieb:
> Auch für die dürfte nicht garantiert sein, dass sie just mit der
> schließenden geschweiften Klammer aufgerufen werden, sondern wohl nur,
> dass sie überhaupt irgendwann mal am Ende der Lebenszeit der Variablen
> gerufen werden. Aber da kenne ich mich in der Tat nicht so genau aus.

Milliarden Zeilen an Mutex-Code verlassen sich darauf.

[Stefan F. (Gast)]

Oliver S. schrieb:
> In C++ ist garantiert, daß der Destruktor aufgerufen wird, wenn die
> Variable out of scope geht.

Leider ist nicht automatisch garantiert, dass der richtige Destruktor 
aufgerufen wird.

Jede Sprache hat ihre Fallstricke. Das C und C++ gut abgehangen sind, 
hat sowohl Vor- als auch Nachteile.

[leo (Gast)]

Stefan ⛄ F. schrieb:
> Leider ist nicht automatisch garantiert, dass der richtige Destruktor
> aufgerufen wird.

Aha. Beispiel fuer "falschen" bitte.

leo

[Stefan F. (Gast)]

leo schrieb:
> Stefan ⛄ F. schrieb:
>> Leider ist nicht automatisch garantiert, dass der richtige Destruktor
>> aufgerufen wird.
>
> Aha. Beispiel fuer "falschen" bitte.

http://stefanfrings.de/qt_lernen/index.html#destruktoren

[Yalu X. (yalu) (Moderator)]

Stefan ⛄ F. schrieb:
> leo schrieb:
>> Stefan ⛄ F. schrieb:
>>> Leider ist nicht automatisch garantiert, dass der richtige Destruktor
>>> aufgerufen wird.
>>
>> Aha. Beispiel fuer "falschen" bitte.
>
> http://stefanfrings.de/qt_lernen/index.html#destruktoren

Natürlich ist nicht automatisch garantiert, dass ein Programm korrekt
abläuft, wenn man absichtlich einen Fehler einbaut (in diesem Fall das
fehlende "virtual"). Oder was wolltest du mit deiner obigen Aussage
ausdrücken?

[Mikro 7. (mikro77)]

Stefan ⛄ F. schrieb:
>...

Wenn du sagst du möchtest die statische Bindung, dann wird das auch so 
ausgeführt. -- Das ist wie typecast auf einen anderen Typ; da kann man 
sich auch nicht beim Compiler beschweren, dass er macht was du 
(fehlerhaft) vorgegeben hast.

[leo (Gast)]

Stefan ⛄ F. schrieb:
>> Aha. Beispiel fuer "falschen" bitte.
>
> http://stefanfrings.de/qt_lernen/index.html#destruktoren

Ja, fehlerhafter Code ist fehlerhaft.

leo

[Jobst Q. (joquis)]

Jörg W. schrieb:
> Vincent H. schrieb:
>> Das hat nämlich tatsächlich Einfluss auf den Code und ist nicht nur "für
>> die Optik" gut...
>
> In erster Linie hat es syntaktischen Einfluss. Einen ordentlichen
> Compiler interessiert das ansonsten nicht.
>
> Ich mache sowas bspw., wenn ich innerhalb eines case-Zweigs eine lokale
> Variable brauche.

Mir fällt nichts ein, wozu es gut sein könnte, mitten in einer Funktion 
neue Variablen zu deklarieren. Deklarationen von lokalen Variablen 
gehören für mich an den Anfang einer Funktion. Damit weiß ich, wo ich 
sie finde, wenn ich sie mal suche.

[leo (Gast)]

Jobst Q. schrieb:
> Mir fällt nichts ein, wozu es gut sein könnte, mitten in einer Funktion
> neue Variablen zu deklarieren.

Natuerlich um den Scope der Variable moelichst klein zu halten.

> Deklarationen von lokalen Variablen
> gehören für mich an den Anfang einer Funktion.

Nein. Das war ein grosser Fortschritt in gcc das zu erlauben.

> Damit weiß ich, wo ich
> sie finde, wenn ich sie mal suche.

Wenn die Variablen dort definiert sind, wo sie verwendet werden, 
ersparst du dir die Suche.

leo

[Jörg W. (dl8dtl) (Moderator)]

Jobst Q. schrieb:
> Mir fällt nichts ein, wozu es gut sein könnte, mitten in einer Funktion
> neue Variablen zu deklarieren.

Ich habe mich da gut dran gewöhnt, dass man Variablen dort definiert, wo 
man sie auch braucht. Dann muss ich nicht erst drei 
(Bildschirm-)Seiten zurück zum Funktionskopf blättern, um die Definition 
einer nur sehr lokal gültigen Variablen zu finden. ;)

Aber das ist Geschmackssache.

[Mikro 7. (mikro77)]

Wenn du nach den Variablen suchen musst ist deine Funktion zu lang.

[Jörg W. (dl8dtl) (Moderator)]

leo schrieb:
> Das war ein grosser Fortschritt in gcc das zu erlauben.

Ist von C++ importiert (und die brauchen das aus anderen Gründen, denn 
die Definition einer Variablen konstruiert dort das Objekt).

Ging natürlich mit einem geschachtelten Brace-Block auch vorher schon, 
aber das sieht viel unübersichtlicher aus.

[Jörg W. (dl8dtl) (Moderator)]

Mikro 7. schrieb:
> Wenn du nach den Variablen suchen musst ist deine Funktion zu lang.

Pauschale Aussagen sind immer falsch. :-))

[Stefan F. (Gast)]

Yalu X. schrieb:
> Natürlich ist nicht automatisch garantiert, dass ein Programm korrekt
> abläuft, wenn man absichtlich einen Fehler einbaut (in diesem Fall das
> fehlende "virtual"). Oder was wolltest du mit deiner obigen Aussage
> ausdrücken?

In diesem Beispiel habe ich das "virtual" absichtlich weg gelassen, um 
den Fehler zu demonstrieren. Im echten Leben passiert so etwas eher 
unabsichtlich.

Mir ist klar, dass die Maschine einen nicht vor jeder Dummheit 
beschützen kann. Hier wäre das wohl nur möglich, indem man die Sprache 
auf nicht abwärts-kompatible Weise ändern würde.

Auf der anderen Seite haben wir dadurch eine gewissen 
Performance-Vorteil, da nur die Funktionen indirekt über die virtual 
table aufgerufen werden, wo es von Programmierer verlangt wurde.

Ich habe Verständnis dafür, das es so bleibt wie es ist.

[Yalu X. (yalu) (Moderator)]

Eine Variable dort zu definieren, wo sie zum ersten Mal gebraucht wird,
hat insbesondere den Vorteil, dass man sie gleich initialisieren kann.
Dadurch ist die Variable zu keinem Zeitpunkt uninitialisiert oder mit
einem sinnlosen Dummy-Wert belegt

[Jemand (Gast)]

Jobst Q. schrieb:
> Mir fällt nichts ein, wozu es gut sein könnte, mitten in einer Funktion
> neue Variablen zu deklarieren. Deklarationen von lokalen Variablen
> gehören für mich an den Anfang einer Funktion. Damit weiß ich, wo ich
> sie finde, wenn ich sie mal suche.

Variablen mit ungültigem Zustandohne Not verfügbar zu machen ist eine 
ganz schreckliche Idee.

[Egon D. (Gast)]

Chris D. schrieb:

> Ich gehöre auch zur "HildeK"-Fraktion: also schön
> die Klammern untereinander. Ich habe damals mal eine
> Umstellung versucht, aber ich konnte mich einfach
> nicht daran gewöhnen, also blieben die Klammern
> untereinander, auch wenn das eine Zeile kostet.

<wunder>

Wie geht denn das? Ich meine mich zu erinnern, dass Du
(auch) umfangreich in Tcl programmierst -- und Tcl
erwartet die öffnende geschweifte Klammern auf derselben
Zeile, auf der das Schlüsselwort steht.

</wunder>

[A. S. (Gast)]

Jobst Q. schrieb:
> Das letzte Zeichen einer Zeile ist ja soo schwer zu finden.

Doch, wenn die Abfrage mehrere Zeilen umspannt oder daran Kommentare 
anschließen. Wenn man sich allerdings an die akademischen Regeln hält 
(Mc Cabe einstellig, Funktion auf einer Seite etc), dann ist das sicher 
ein wertvoller Stil.

[Rolf M. (rmagnus)]

Jörg W. schrieb:
> Oliver S. schrieb:
>> Es soll ja gerüchteweise auch Programmiersprachen mit Destruktoren
>> geben.
>
> Auch für die dürfte nicht garantiert sein, dass sie just mit der
> schließenden geschweiften Klammer aufgerufen werden, sondern wohl nur,
> dass sie überhaupt irgendwann mal am Ende der Lebenszeit der Variablen
> gerufen werden. Aber da kenne ich mich in der Tat nicht so genau aus.

In C++ ist das garantiert. Deshalb funktioniert dort das RAII-Konzept.
In GC-Sprachen kann man sich aber in der Regel nicht auf Destruktoren 
verlassen, sondern muss die Ressourcen manuell freigeben. Das ist die 
Crux bei der Garbage Collection. Sie kümmert sich um den Speicher, führt 
aber gleichzeitig dazu, dass man andere Ressourcen manuell freigeben 
muss, weil das mangels deterministischer Destruktoren nicht mehr 
automatisiert werden kann.

Jobst Q. schrieb:
>> Ich mache sowas bspw., wenn ich innerhalb eines case-Zweigs eine lokale
>> Variable brauche.
>
> Mir fällt nichts ein, wozu es gut sein könnte, mitten in einer Funktion
> neue Variablen zu deklarieren.

Und mir fällt nichts ein, wozu es gut sein könnte, sich eine Variable 
nicht dort zu definieren, wo man sie braucht, schon ein Stück davor, und 
sie dann bis zur Verwendung brach liegen zu lassen.