Schön, dass du gegen Dinge "argumentierst", die so niemand behauptet hat. Dafür ein Fleißbienchen für dich
ist jahrelange Praxis weder eine notwendige noch eine hinreichende Bedingung für die Fähigkeit, guten Code zu produzieren)
Ich hatte das so interpretiert: Man guten Code auch ohne Praxis/Erfahrung produzieren. Und das stimmt nicht. Kein Handwerk ohne Praxis. Je mehr, desto besser.
Zitat:
Falsch. Es drückt eben gerade NICHT aus, _WAS_ passieren soll, sondern _WIE_ etwas passieren soll
break => 'raus hier'. Continue => 'weiter im Text'. Wir haben unterschiedliche Auffassungen von 'WAS' und 'WIE' (im linguistischen Kontext).
Zitat:
Im Übrigen geht es nicht darum, ob case, break, for, etc legitime Anwendungsfälle haben, denn das ist zweifelsfrei schon allein dann der Fall, wenn eine Sprache (resp. Library) nichts bessers zu bieten hat.
Jetzt kommen wir der Sache näher bzw. nähern uns an und marschieren ja in die gleiche Richtung.
Deine restlichen Ausführungen gebe ich hier nicht wieder, ziehe meine Polemik zurück und werfe dennoch ein, das Du es dir ein wenig zu leicht machst: Es gibt mehr als 'schlechten Stil' und 'guten Stil'. Ich arbeite gerade mit SPS-Programmierern zusammen, die eine PASCAL-ähnliche Sprache verwenden und es ist eine Herausforderung, hier sauberen Code zu erstellen. Insofern ist das, was hier 'gut' ist, unter C# z.B. oller Tobak.
For-Schleifen werden in moderneren Programmiersprachen überflüssig, da hast Du Recht. Nicht weil sie böse sind, sondern weil es Wege gibt, die Lösung eines Problemes einfacher und direkter zu beschreiben. Ich schrieb ja, das es keine Dogmen geben sollte, sondern nur dieses eine Ziel: Code lesbar, wartbar, robust zu schreiben. Das wir das gleiche Ziel verfolgen, scheint mittlerweile klar.
Code riecht gut, wenn er verstanden wird. Code riecht nicht gut, wenn er erklärt werden muss.