Klar: Ich kauf mir Bücher darüber, wie man Autos repariert und -wupps- bin ich Mechaniker.
Und dann kauf ich mir noch Bücher, wie man guten Code produziert, zitiere daraus und -täterää- bin ich guter Programmierer. Selten so gelacht.
Schön, dass du gegen Dinge "argumentierst", die so niemand behauptet hat. Dafür ein Fleißbienchen für dich
Zitat:
Aber trotzdem gibt es noch Leute, die es ablehnen. Na ja, kann natürlich Codeschmell sein. Für mich ist das: "Klare Sprache, um auszudrücken, was jetzt passieren soll".
Falsch. Es drückt eben gerade NICHT aus, _WAS_ passieren soll, sondern _WIE_ etwas passieren soll, und genau da liegt der Hase im Pfeffer. 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.
Zitat:
Denk mal darüber nach, wie viel einfacher und klarer Programme wären, wenn man keine Dogmen aufstellt ("break, continue, case sind böse"), sondern auf einer Ebene darüber (inklusive über den Tellerrand blicken und so) über den perfekten Code siniert: Erst dann kommt man weiter.
Stell dir vor, weil ich _genau das_ bereits getan habe bzw. kontinuierlich tue, komme ich zu genau dem Schluss, dass Dinge wie break, continue, case of oder for-Schleifen im Endeffekt Code-Krüppel aus vergangenen Zeiten sind. Natürlich verwende ich die, solange ich nichts besseres habe, und natürlich ist ein continue u.U. lesbarer als was auch immer für Alternativen. Das alles ändert aber einfach nichts daran, dass das - verglichen mit dem, was möglich wäre - schlechter Code ist.
Um nur mal ein Beispiel zu bringen... Gegeben sei eine Liste von Personen, gesucht sind die Voll- und Minderjährigen. In Scala kann ich das machen:
Code:
val people = List(...)
val (minors, adults) = people.partition(person => person.age < 18)
Jetzt kommst du mit deiner for-Schleife.