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.
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 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.
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.
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:
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.
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
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 ...
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.
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:
1
#include<stdio.h>
2
3
intfunc(inta,intb)
4
{
5
if(a<b)
6
printf("A ist kleiner als b\n");
7
returna;
8
returnb;
9
}
führt bei -Wall zu folgender Ausgabe des Compilers:
1
indentation.c: In function ‘func’:
2
indentation.c:5:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
3
5 | if (a < b)
4
| ^~
5
indentation.c:7:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
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.
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.
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.
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.
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.
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. ;-)
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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").
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...
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. ;-)
Ich hoffe ja stark, dass der popelnde corona patient die Minuspunkte für
das Popeln bekommt. if ohne geschweifte Klammern ist keineGeschmackssache sondern Sabotage und eine Gemeinheit gegen die
Kollegen.
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.
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.
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 ...
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. ;-)
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.
... Geschmack berührt immer!
anderes Beispiel:
//my approach, easy to detect
while (...) continue;
//other variants
while (...);
while (...) {}
while (...)
;
while (...)
{}
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.
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. ;-)
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.
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.
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.
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 ... ?
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:
1
#define wrapline() if (col > cols) wrapit (currentline) // für die Einzeilen-if-Schreiber ;-)
In der C-Datei:
1
if(linetoolong)
2
wrapline();
3
else
4
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
1
if(linetoolong)
2
{
3
wrapline();
4
}
5
else
6
{
7
do_something_other();
8
}
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.
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
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.
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:
1
#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.
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.
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.
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>
1
>if(linetoolong)
2
>{
3
>wrapline();
4
>}
5
>else
6
>{
7
>do_something_other();
8
>}
9
>
>
Aus genau diesem Grund pack ich auch bei Einzelanweisungen diese immer
in einen (einzeiligen) Klammerblock:
1
if(linetoolong){wrapline();}
2
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?
1
if(blub){
2
foo();
3
bar();
4
}
5
else{
6
bar();
7
foo();
8
}
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.
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.
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:
1
#include<stdio.h>
2
#define NEG(a) -a
3
4
intmain()
5
{
6
intx=3;
7
8
printf("negative value of -3 is %d\n",NEG(-x));
9
return0;
10
}
Übersetzt und ausgeführt:
1
cc neg.c -o neg && ./neg
2
negative value of -3 is 3
Viele C-Compiler haben da noch vor ein paar Jahren folgendes ausgegeben:
1
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.
[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:
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?)
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.
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.
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.
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. ;-)
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.
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 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:
1
gcc -traditional-cpp -E n.c
Ergebnis:
1
# 1 "n.c"
2
# 1 "<command-line>"
3
# 1 "n.c"
4
5
intmain()
6
{
7
intx=3;
8
9
printf("negative value of -3 is %d\n",--x);
10
return0;
11
}
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:
1
"You need a ISO C conforming compiler to use the glibc headers"
P.S.
Stichwort für weitere Recherche ist hier "Token Spacing"
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 ...
Jörg W. schrieb:> Frank M. schrieb:> Die Compilerbauer haben mittlerweile dazugelernt. ;-)>> Vermutlich haben auch die Standardisierer dazu gelernt.
Das trifft es vermutlich besser.
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:
1
intfoo()
2
{
3
autof=
4
[]()
5
{for(intc1=0;c1<3;c1++)
6
{
7
for(inti=0;i<5;i++)
8
{
9
for(intc2=0;c2<3;c2++)
10
{
11
}
12
}
13
}};
14
}
Leider verkennt die Forensoftware die eigentliche Schönheit dieser
Formatierung ;)
Oliver
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.
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
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.
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:
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:
1
voidtuwas(Useruser)
2
{
3
CreateUserRequestr=newCreateUserRequest();
4
{
5
r.setFirstName(user.getFirstName());
6
r.setLastName(user.getLastName());
7
r.setBirthDate(user.getBirthDate());
8
9
Addressa=newAddress();
10
{
11
a.setStreet(user.getStreet());
12
a.setHouseNumber(user.getHouseNumber());
13
a.setZipCode(user.getZipCode();
14
a.setCity(user.getCity());
15
a.setCountry("Germany");
16
}
17
r.setAddress(a);
18
}
19
createUserImpl.invoke(r);
20
}
Ich weiß, es gibt elegantere Alternativen. Aber so sieht es auch schon
wesentlich übersichtlicher aus, als ohne die Klammern.
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.
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.
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).
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.
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.
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....
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.
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.
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.
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
Oder - kurz und knackig - eine Null-Pointer-feste Variante von strlen():
1
INTlength(as)
2
STRINGas;
3
{
4
REGSTRINGs;
5
6
IFs=asTHENWHILE*s++DONEFI
7
return(s-as);
8
}
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.
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.
Chris D. schrieb:> "HildeK"-Fraktion
Nett ?, obwohl ich vermutlich der Einzige bin in dem Thread, der nur
Hobby-Amateur-Gelegenheits-Softwerker ist ...
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. :-(
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
...
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);
}
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...
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:
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
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.
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.
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.
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
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.
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.
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
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.
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.
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?
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.
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.
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
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.
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.
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.
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
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.
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>
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.
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.