case...of für mehrere Variablen?

[Furtbichler]

Zitat von Meflin:

Wie sagte unser Softwaretechnik-Prof so schön? Ein case-of ist an sich schon ein Code-Smell.

Na mit dem Warmduscher und Theoriefuzzi würde ich mich mal gerne unterhalten. Und natürlich lass ich mich gerne belehren. Aber Profs im Allgemeinen sind naturgemäß nicht sehr nahe an jahrelanger Praxis.

Viele IF-THEN's hintereinander sind natürlich mumpitz, weil man die Heuristik immer refaktorisieren sollte. Und das wurde ja schon erwähnt (mindestens ein sauberer Ansatz bisher).

Und deinem Prof kannst Du sagen, das eine Fallunterscheidung kein Codesmell ist, sondern durchaus gängige Praxis und auch nichts anderes als Mathematik. Wobei man über die Anzahl der Fälle durchaus diskutieren kann. Eine Classfactory ohne Case-Konstrukt ist z.B. nicht sonderlich übersichtlich.

Eine komplette Fallunterscheidung (sei es durch IFs oder CASEs) taugt im Übrigen als informeller Beweis der Vollständigkeit einer Umsetzung.

Ach egal. Wird schon wieder ein Glaubenskrieg.

[blackfin]

Zitat:

...Theoriefuzzi...

Made my day

Das denke ich mir allerdings auch oft, wenn jemand nur das wahre und reine OOP predigt.
Nichts, dass ich generell etwas gegen OOP hätte, im Gegenteil, aber leider sind oft genau das dann die Leute, die in der Praxis sich so ihrer Abstraktion verzettelt, dass das resultierende Projekt
1) Nie fertig wird
2) Noch unwartbarer wird, als hätte man Spaghetticode geschrieben, weil man vor lauter Abstraktionswahn alles vollkommen gegen die Wand gefahren hat.
Der Code ist dann vielleicht im Lehrbuch schön und mega flexibel, aber kaum noch benutzbar.

[Meflin]

Zitat von Furtbichler:

Aber Profs im Allgemeinen sind naturgemäß nicht sehr nahe an jahrelanger Praxis.

Ach ja, das gute alte nicht-Argument. Sorry, du bist disqualifiziert (... und im Übrigen ist jahrelange Praxis weder eine notwendige noch eine hinreichende Bedingung für die Fähigkeit, guten Code zu produzieren).

Zitat:

... sondern durchaus gängige Praxis und auch nichts anderes als Mathematik

Gängige Praxis ist kein Ausschlußkriterium für einen Code-Smell. 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.

Zitat:

Eine Classfactory ohne Case-Konstrukt ist z.B. nicht sonderlich übersichtlich.

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.

Aber ja, die Diskussion wird Meta...

[Iwo Asnet]

Zitat von Meflin:

...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. 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
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 von Iwo Asnet:

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.

[Bummi]

contenance

[Daniel]

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

[Iwo Asnet]

Zitat von Meflin:

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

Zitat von Meflin:

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.