Wieso ist das Programm ein Alptraum?

[Programmierfachprofi]

Marc++us schrieb:

@Programmierfachprofi:

Man sieht deutlich, daß Deine Variante semantisch gleich ist, durch die notwendige Duplizierung von Code aber fehleranfälliger und damit auch schlechter wartbar. Dein Beispiel war eigentlich wunderbar geeignet, um die Vorteile eines goto zu beleuchten.

Deine Sprungmarken erhöhen ebenfalls die Zeilenanzahl und somit die Fehleranfälligkeit.
Außerdem kann ein Compiler so ein Konstrukt nicht mehr so gut optimieren, das dürfte das Totschlagargument für GOTO sein.

cooky451 schrieb:

da fehlt ein closeFile().

Bitteschön:

int foo(....){
  if (!openDataFile())
    return 1;
  if (!getDataFromFile())
  {
    closeFile();
    return 1; /* oder 2, wer damit was machen will (z.B. Ausgabe der
                 Fehlermeldung oder weiterführende delegierte Fehlerbehandlung
                 etc. */
  )
  if (!allocateSomeResources)
  {
    freeResources();
    closeFile();
    return 1; // siehe oben
  }

  // Do more work here....
  freeResources();

  // free resources
  closeFile();

  // close file
  return 0;
  // quit!
}

[Programmierfachprofi]

knivil schrieb:

Beispielsweise folgender suaberer Code ist trotzdem schwer zu lesen

Bei den Variablennamen wundert mich das auch nicht.

Daher Definieren wir:
sauberer Code = enthält gute aussagekräftige Variablennamen

[Bitte ein Bit]

Daher Definieren wir:
sauberer Code = enthält gute aussagekräftige Variablennamen

Grins
Extremes Negativbeispiel, welches ich kennenlernte:

double FestgelegteRotationKXYZPXYZ::GetWert()
{
  return Variablen[VariablenIndizes[1]]*sin(Variablen[VariablenIndizes[2]])+Variablen[VariablenIndizes[2]]*Variablen[VariablenIndizes[0]]+cos(Variablen[VariablenIndizes[3]])+Variablen[VariablenIndizes[4]]*Variablen[VariablenIndizes[1]]*sin(Variablen[VariablenIndizes[3]];
}

[Marc++us]

Programmierfachprofi schrieb:

Deine Sprungmarken erhöhen ebenfalls die Zeilenanzahl und somit die Fehleranfälligkeit.

Zeilenanzahl ist ungleich Komplexität, damit ohne Zusammenhang zur Fehleranfälligkeit.

Aber die Notwendigkeit Code zu duplizieren und bei Änderungen an jeder Duplikationsstelle mitzuändern ist extrem fehleranfällig.

Programmierfachprofi schrieb:

Außerdem kann ein Compiler so ein Konstrukt nicht mehr so gut optimieren, das dürfte das Totschlagargument für GOTO sein.

Hm? Woraus leitest Du das ab? Da diese Form der goto-Fehlerbehandlung gerade in Unix-Kernels verwendet wird UND deren Übersetzung ein Standardbenchmark für jeden Compiler ist, haben die mit hoher Wahrscheinlichkeit darüber nachgedacht.

Für den Compiler ist das goto ja nur ein weiterer Pfad... es gibt einmal den regulären Pfad, und dann welche mit goto. Der Compiler baut sich darauf seinen Ablaufgraph auf und optimiert entlang des Ausführungspfads. Es zwar richtig, daß man von goto aus jedem Kontext rausspringen kann, aber wenn das Programm übersetzt wird sind alle diese Exit-Punkte dem Compiler bekannt.

[seldon]

cooky451 schrieb:

seldon schrieb:

als der gleiche Code

Konsequent weitergedacht bedeutet das, dass keine Funktion mehr als eine Ressource reservieren darf.

Das hab ich damit nicht gemeint, sondern, dass eine Funktion, die sich mit Ressourcenallokation beschäftigt, (fast)* nur mit Ressourcenallokation beschäftigen sollte, und nicht mit der Verwendung selbiger. Das kann dann ruhig auch ne static-Funktion direkt über der verwendenden Funktion sein.

Damit hat man den fummeligen Teil an einer Stelle, kommt aus der Ressourcenanforderung in einem von zwei Zuständen wieder raus ("alles geklappt, Ressourcen angefordert" oder "ist was schief gegangen, alles schon wieder aufgeräumt") und ist einen Großteil der Komplexität los.

Wenn man in einer Funktion mehrere Ressourcen braucht, wird man, wie gesagt, die Kaskade nicht unbedingt los, aber man hat sie isoliert -- und eine Funktion, die sich nur mit der Anforderung von so Größenordnung drei Kontextobjekten beschäftigt, kriegt man mit oder ohne goto lesbar gebacken (ich mach das dann lieber ohne). Wenn man in einer Funktion deutlich mehr einzelne Ressourcenanforderungen hat, hat man aus meiner Sicht noch ganz andere Strukturprobleme -- das schlägt dann in die selbe Bresche wie die Funktionen-sollten-nicht-länger-als-50-Zeilen-lang-sein-Faustregel.

* nach Sachlage im Einzelfall zu beurteilen

[Programmierfachprofi]

Marc++us schrieb:

Programmierfachprofi schrieb:

Deine Sprungmarken erhöhen ebenfalls die Zeilenanzahl und somit die Fehleranfälligkeit.

Zeilenanzahl ist ungleich Komplexität, damit ohne Zusammenhang zur Fehleranfälligkeit.

Aber die Notwendigkeit Code zu duplizieren und bei Änderungen an jeder Duplikationsstelle mitzuändern ist extrem fehleranfällig.

Deswegen lagert man das in Funktionen aus, benutzt inline-ersetzung oder Funktionsmakros.

Programmierfachprofi schrieb:

Außerdem kann ein Compiler so ein Konstrukt nicht mehr so gut optimieren, das dürfte das Totschlagargument für GOTO sein.

Hm? Woraus leitest Du das ab? Da diese Form der goto-Fehlerbehandlung gerade in Unix-Kernels verwendet wird UND deren Übersetzung ein Standardbenchmark für jeden Compiler ist, haben die mit hoher Wahrscheinlichkeit darüber nachgedacht.

Weil ein Compiler nicht wirklich weiß, wo im Spagetthicode die Sprungmarke ist.
D.h. er findet sie zwar schon, aber eine Kenntnis über eine strukturierte Verschachtelung fehlt ihm völlig und mit diesem fehlenden Wissen kann er nur schlecht optimieren.

Das es Standardbenchmakrs für Compiler gibt ist klar, immerhin wird das für den Compiler sehr schwer, da noch etwas zu optimieren.
Die Standardbenchmarks zeigen also, dass gotos zu optimierproblemen führen.

Wenn ich meinen Compiler stattdessen mit einem ordentlich strukturierten Code füttere, so wie man es früher mit Pascal gelernt hat, dann weiß der wenigstens wo er optimieren kann und das macht er dann sehr gut.

Für den Compiler ist das goto ja nur ein weiterer Pfad... es gibt einmal den regulären Pfad, und dann welche mit goto. Der Compiler baut sich darauf seinen Ablaufgraph auf und optimiert entlang des Ausführungspfads.

Dem Ablaufgraph fehlt allerdings die Schachtelung, wenn der Programmierer sich mit den Gotos dumm angestellt hat.

[knivil]

Zeilenanzahl ist ungleich Komplexität, damit ohne Zusammenhang zur Fehleranfälligkeit.

Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert. Das soll unabhaengig von Sprache, Programmierstil etc. Also etwa 100 Zeilen ein Bug. Siehe http://de.wikipedia.org/wiki/Fehlerquotient wobei ich in den Quellen nicht nachgelesen habe.

[icarus2]

Auch wenn goto grundsaetzlich gemiden werden sollte gibt es durchaus ein paar Ausnahmen, z.B.:
1. Um aus einer verschachtelten Schleife rauszuspringen (muss man wohl kaum erklaren unter welchen Umstaenden das wuenschenswert ist.
2. Nested Cleanup Code (wird zum Beispiel auch im Linux Kernel so gemacht).

@ Programmierfachprofi
Warum sollte ein Compiler strukturierten Code besser optimieren koennen als Code mit goto? Kannst du ein konkretes Beispiel geben bzw. etwas ausfuehrlicher sein?

*Edit
Auf http://www.systems.ethz.ch/courses/fall2012/SPCA in der 10. Vorlesung "Advanced C" gibts einen Abschnitt "goto" und dort gibts Beispiele zu Punkt 1 und 2.

[knivil]

Ich finde nicht, dass der Linuxkernel ein gutes Beispiel ist. Die meisten werden doch eher Anwendungssoftware schreiben, d.h. ist das Argument fehl am Platz.

1. Um aus einer verschachtelten Schleife rauszuspringen

Gar nicht erst verschachtelte Schleifen schreiben.

*Edit
Auf http://www.systems.ethz.ch/courses/fall2012/SPCA in der 10. Vorlesung "Advanced C" gibts einen Abschnitt "goto" und dort gibts Beispiele zu Punkt 1 und 2.

Und fuer Punkt 1.) wurde die Alternative gleich genannt und Punkt 2.) bezieht sich auf den Kernel.

[Bashar]

icarus2 schrieb:

@ Programmierfachprofi
Warum sollte ein Compiler strukturierten Code besser optimieren koennen als Code mit goto? Kannst du ein konkretes Beispiel geben bzw. etwas ausfuehrlicher sein?

Das Problem ist nicht goto per se, sondern ein irreduzibler Kontrollflussgraph. Damit funktionieren einige Optimierungsalgorithmen nicht. Mein Wissen reicht auf dem Gebiet aber nicht über Halbwissen hinaus, deshalb soll das an der Stelle genügen. Ein google-Stichwort hab ich ja gegeben.

[Marc++us]

Bashar schrieb:

sondern ein irreduzibler Kontrollflussgraph.

... aber der liegt in den hier gezeigten Beispielen doch kaum vor. Das ist ungefähr vergleichbar wie ein Switch-case.

[icarus2]

knivil schrieb:

Ich finde nicht, dass der Linuxkernel ein gutes Beispiel ist. Die meisten werden doch eher Anwendungssoftware schreiben, d.h. ist das Argument fehl am Platz.

Mein Punkt war nicht, dass jeder Verwendung dafuer findet sondern bloss, dass eine kategorische Ablehnung gegenueber goto nicht berechtigt ist.

knivil schrieb:

Gar nicht erst verschachtelte Schleifen schreiben.

Dass man in stinknormaler Anwendungssoftware keine verschachtelten Schleifen braucht kann ich noch glauben (ich weiss es nicht, denn ich habe leider noch nie als Softwareentwickler gearbeitet). Aber bei gewissen Algorithmen frage ich mich schon wie man da um verschachtelte Schleifen rumkommt.

Mir ist klar, dass die meisten Programmierer damit nie konfrontiert werden. Mein Punkt war bloss, dass in gewissen Bereichen goto durchaus Verwendung findet. Auch wenn die meisten das nie brauchen schadet es nicht das zu wissen.

@ Bashar:
Thx fuer das Stickwort. Werde mal danach googeln.

[Marc++us]

knivil schrieb:

Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert.

Absolut gesehen ja.

Ich habe es hier auf das Beispiel von ihm bezogen, ich glaube ich habe eine Zeile mehr, weil ich für goto + Label eine Zeile mehr brauche als seine Lösung.

[knivil]

Mein Punkt war bloss, dass in gewissen Bereichen goto durchaus Verwendung findet.

Das zweifelt niemand an. Dennoch ist es in den meisten Faellen eine schlechte Idee.

[Marc++us]

knivil schrieb:

Ich finde nicht, dass der Linuxkernel ein gutes Beispiel ist.

Das Originalbeispiel war Anprogrammierung von Grafik... also typische Init-Exit-Sachen von Grafikstruktur hier, Port da, etc.

Die Masse der Leute hier wird ja hoffentlich die Anwendungen auch nicht in C schreiben...

[knivil]

Ich halte das ganze fuer einen Trollpost.

[assembl0r]

Marc++us schrieb:

Die Masse der Leute hier wird ja hoffentlich die Anwendungen auch nicht in C schreiben...

ach, die masse ...
richtige programmierer schreiben es in assembler

[Bitte ein Bit]

Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert. Das soll unabhaengig von Sprache, Programmierstil etc. Also etwa 100 Zeilen ein Bug.

Das ist wohl der Grund warum einige Programmierer viel Code in eine Zeile packen...

if (a==0) {b=5;c=6;d=-1}
switch (a) {
  case 0: b=5;c=4;break;
}

:xmas1:

Alle unnötigen Leerzeichen entfernen und soviel wie möglich in eine Zeile packen s.d. man möglichst wenig LOC hat s.d. man möglichst wenig Fehler hat.

[SeppJ]

Theoretisch braucht man nirgendwo Zeilenumbrüche. Der Zeilenumbruch hat keine besondere Bedeutung in C (außer dass er auch ein Whitespace ist).

[cooky451]

Das werde ich ab jetzt ausnutzen, offenbar hilft es ja dabei Bugs zu vermeiden.