case...of für mehrere Variablen?

[Iwo Asnet]

Zitat:

Zitat von Meflin (Beitrag 1173487)

...im Übrigen ist jahrelange Praxis weder eine notwendige noch eine hinreichende Bedingung für die Fähigkeit, guten Code zu produzieren).

Klar: Ich kauf mir Bücher darüber, wie man Autos repariert und -wupps- bin ich Mechaniker. :-D 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.

Zitat:

Auch break und continue sind gängige Prxis und trotzdem nichts anderes als bessere Gotos. Und sorry, wenn die Sprache einen mehr oder weniger zwingt sowas zu verwenden, dann ist eben die Sprache sch***e. Und trotzdem ist's ein Smell.

He he, "break" und "continue" werden von Clean-Code Verfechtern (praxisorientiert ;-) ) propagiert, alle Refactoring-Tools, die ich kenne, propagieren das. 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".

Zitat:

Maps aka Dictionaries ersetzen gefühlte 90% aller case-Konstrukte in solchen Fällen mehr als gut und haben dabei sogar noch die passende Semantik.

Das ist korrekt, aber nicht notwendigerweise lesbarer.

Nur, weil man ohne 'case', 'break', 'continue', und (ja, einige fordern das sogar) 'for' auskommen kann, heißt das nicht, das diese Konstrukte überflüssig bzw. code smell sind. In der Folge wäre nur RISC wirklich 'Clean'.

Das Motto muss lauten: "So lesbar wie möglich mit so wenig Code wie nötig" und nicht "So wenig keywords wie nötig". Dann ist das guter Code.
Ein Case-Konstrukt aus 1000 Fällen ist per se Blödsinn, aber 3-4 Fallunterscheidungen sind allemal übersichtlicher als irgendwelche Maps oder Dictionaries, die an ganz anderer Stelle befüllt werden:

Delphi-Quellcode:

Case WerteBereich(Messwert) of
  ZuKlein :
    GibFehlermeldungAus('Der Wert ist zu klein');
  GeradeRichtig :
    VerarbeiteDen(MessWert);
  ZuGross :
    GibFehlermeldungAus('Der Wert ist zu groß');
end;

erfordert keine Zeile Kommentar, wohingegen

Delphi-Quellcode:

WerteBereichAuswertungsDictionary[WerteBereich(Messwert)]();

kurz und knapp ist, aber nicht gerade lesbarer. Als Programmierer muss ich nachdenken, was der Code macht. Und blättern muss ich auch, um herauszubekommen, was unter welchen Umständen ausgeführt werden soll. Mist, schon wieder 10 Sekunden unnütz nachgedacht, nur weil der Programmierer zu faul ist, sich klar und verständlich auszudrücken.

Abschließend noch eins:
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.

[Meflin]

Zitat:

Zitat von Iwo Asnet (Beitrag 1173504)

Klar: Ich kauf mir Bücher darüber, wie man Autos repariert und -wupps- bin ich Mechaniker. :-D 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 :thumb:

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.

[Bummi]

contenance

[Daniel]

Ja, den Rest klärt Ihr bitte per PN.

[Iwo Asnet]

Zitat:

Zitat von Meflin (Beitrag 1173532)

Schön, dass du gegen Dinge "argumentierst", die so niemand behauptet hat. Dafür ein Fleißbienchen für dich :thumb:

Zitat:

Zitat von Meflin (Beitrag 1173487)

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.