Ich bin ein hardwarenaher Programmierer.
Damit bin ich natürlich in meiner Einstellung zum Programmieren etwas voreingenommen.
Aber abgesehen davon gehört zum Programmieren philosophischer Streit dazu!
Ein Aspekt, der bei der Planung eines Programmes oft unterschätzt wird, ist die Übersichtlichkeit des Sourcecodes. Die meisten Programmierfehler, gerade die, die zu unerwartetem Datenverlust führen, kommen dadurch zustande, dass der Programmierer keinen vollständigen Überblick mehr über das Programm hat.
Ein sauberes Interface zwischen den Programmteilen hilft nichts, wenn man nicht genau weiß, was in dem anderen, angesteuerten Programmteil vor sich geht.
Dann macht man nämlich etwas, was lokal erst einmal richtig ist, aber in dem anderen Programmteil zu Störungen führt.
Der optische Eindruck eines Programms sollte nicht im Vordergrund stehen. Viel wichtiger ist, dass es möglichst einfach zu bedienen ist.
Goto considered useful
Ein berühmter Programmiertheoretiker (Edsger W.Dijkstra, Commun. ACM 11 1968,3, 147-148) meinte einmal, das goto-statement wäre schädlich, da sich Rücksprünge immer als for-schleifen, und Vorwärtssprünge als if-Anweisungen mit Klammern und umgekehrten Bedingungen schreiben ließen. Diese seien - natürlich - übersichtlicher. Von Programmiertheoretikern wurde das sehr wohlwollend aufgenommen, wollen diese doch, dass sich die Logik eineindeutig in Programmcode übersetzen lässt. Ein goto erklärt nichts, ist daher nur eindeutig.
Diese Einstellung hat jedoch eine Kehrseite: für kompliziertere Konstrukte fordern diese Theoretiker dann meist neue Statements, so dass die Programmiersprachen immer komplexer werden - und man dann immer wieder eine neue Version des Compilers braucht.
Dass goto in der Praxis sinnvoll sein kann, erkannte auch Linus Torvalds, der diese Anweisung oft zum Überspringen mehrerer Anweisungen verwendete. in seinem Treiberland, CPL=0, sähen indentierte if-Anweisungen zum Überspringen auch völlig unübersichtlich aus, da die Bedingungen dann kompliziert wären.
Ich finde, goto ist absolut notwendig, wenn aus einem Loop herausgesprungen wird. Dies wird ja normalerweise bedingt gemacht. Was nun, wenn man beim verbessern des codes diese Bedingung in einen loop einschließt. Wird mit continue gearbeitet, so springt continue aus gar nichts raus außer aus der Frage, ob gerade rausgesprungen werden soll. Die Umkonstruktion hat das Sprungziel verfälscht. Und wenn man mit continue 2 rausspringt, dann hat man sozusagen einen "berechneten Sprung", der noch fehleranfälliger für die nächste Erweiterung und schon gar nicht übersichtlicher ist!
Und weil Programmieren so viel Spaß macht, entwickle ich natürlich auch Patches.
MEINE PATCHES