case...of für mehrere Variablen?

[Boyington]

Morgen Zusammen,
wie "case...of" für EINE Variable in Delphi zu verwenden ist mir ganz klar, aber wie mache ich mit "case...of" für mehrere Variablen?

Beispiel:
if (a=0 und b=0) then Anweisung1
else if (a=0 und b>0 und b<10) then Anweisung2
else if (a=0 und b=10) then Anweisung3
else if (a>0 und a<5 und b=0) then Anweisung4
else if (a>0 und a<5 und b=10) then Anweisung5
else if (a=5 und b=0) then Anweisung6

mit if...then...else kann ich die entsprenchde Funktion realisieren, aber sieht nicht so schön aus, wie kann ich es durch case...of oder andere passenden code ordentlich und übersichtlich ersetzen?

Danke für die Hinweise im Voraus!

Gruss
Lee

[Bummi]

Von der entsprechenden Stelle verlagern oder umformulieren geht, viel mehr nicht

Delphi-Quellcode:

Function Comp2(a,b:Integer):Integer;
begin
   case a of
   0:
        begin
           case b of
             6..9:  Result := 1;
             10  :  Result := 2;
           end;
        end;
   1..4:
        begin
           ....
        end;
   5:
        begin
          .....
        end;
   end;
end;

Function Comp1(a,b:Double):Integer;
begin
if (a=0) then
  begin
   if (b>5)and (b<10) then result := 1
   else if (b=10) then Result := 2;

  end
else if (a>0) and (a<5)then
  begin
    if b=0 then Result := 3
    else if b=10 then Result := 4;
  end
else if (a=5) then
  begin
   if b=5 then result := 5
  end
end;

procedure TForm2.Button1Click(Sender: TObject);
var
 a,b:Double; //Integer;
begin
 a := 0;
 b := 6;
     case comp1(a,b) of // oder comp2
        1:Showmessage('1');
        2:Showmessage('2');
        3:Showmessage('3');
        4:Showmessage('4');

     end;
end;

[Furtbichler]

Deine Heuristik (also die if-then-else-Dinger) entscheiden anhand von Bedingungen, was als nächstes zu zun ist.
Was bedeutet es denn, wenn a=0 und b=0 ist?
Und was, wenn a=0 aber b zwischen 1 und 9?

Erstelle eine Enumeration, die die Ergebnisse der Einzelentscheidungen wiederspiegelt. Z.B.

Delphi-Quellcode:

Type
  TErgebnisse = (erKeinErgebnis, erAllesIstNull, erNurBistOK, erNurAIstOK,erBAußerhalb, erAAußerhalb,erAIstOkUndBAußerhalb);

Function ParameterAuswertung (a,b : Integer) : TErgebnisse;
Begin
  if (a=0 und b=0) then 
    Result := erAllesIstNull
  else if (a=0 und b>0 und b<10) then 
    Result := erNurBistOK
  else if (a=0 und b=10) then 
    Result := erBAußerhalb
  else if (a>0 und a<5 und b=0) then 
    Result := erNurAIstOK
  else if (a>0 und a<5 und b=10) then 
    Result :=erAIstOkUndBAußerhalb
  else if (a=5 und b=0) then 
    Result := erAAußerhalb
  else
    Result := erKeinErgebnis
End;

...

Case  ParameterAuswertung (a,b) of
  erKeinErgebnis :  
    Fehler!
  erAllesIstNull : 
    Anweisung1; 
  erNurBistOK :
    Anweisung2; 
  erNurAIstOK :
    Anweisung3;
  erBAußerhalb :
    Anweisung4; 
  erAAußerhalb :
    Anweisung5; 
end;

(Das soll nur ein Beispiel sein und ist nicht 1:1 mit deinem Code kompatibel)
Die schlecht lesbare Auswertung ist verlagert, dafür ist der Code nun viel übersichtlicher und beschreibt sich wesentlich genauer.

Aus schlecht lesbarem (richtig beobachtet) Kauderwelsch wird so sehr gut lesbarer Code. Dieser ist nun auch leicht erweiterbar und durch das Umformen wurde ein Fehler sichtbar (keine Defaultaktion, Entscheidungsfindung war unvollständig)

Alternativ kannst Du nun deine Entscheidungsfindung (ist A zu klein, zu groß, ok? und B?) noch verfeinern bzw. refaktorisieren.

[himitsu]

Einige Möglichkeiten wurden ja schon genannt.

- viele IFs

- umrechnen in einen Index, wozu auch die Enumeration gehört
Das kann man übrigens auch für Strings und andere nicht ordinale Typen verwenden, indem man z.B. über einen Hash oder z.B. IndexStr geht.

Und dann kann man die Werte auch noch einfach
- zusammenrechnen

Delphi-Quellcode:

case a*100 + b of
  0000: Anweisung1;
  0001..0009: Anweisung2;
  0010: Anweisung3;
  0100, 0200, 0300, 0400: Anweisung4;
  0110, 0210, 0310, 0410: Anweisung5;
  0500: Anweisung6;
  else ;
end;

Aber das geht meistens am Besten, wenn ein Wert fortlaufend ist und der Andere möglichst immer jeweils nur zu einem oder wenigen ersten Wert(en) gehört (siehe Anweisung 4 und 5), da man Bereiche nur für einen Wert definieren kann.

[Furtbichler]

Es ging um Übersichtlichkeit. Das viele Wege nach Rom führen, ist bekannt.

[himitsu]

Tja und da hängt es von den Ausgangsdaten ab.
Jenachdem wie dieses aussehn, macht sich das Eine besser oder was Anderes
und jede Möglichkeit ist dabei auch unterschiedlich übersichtlich,
wobei hier auch das IF am übersichtlichsten sein kann.

Der Enum gegenüber dem Index macht sich vorallem gut, wenn man die einzelnen Bereiche gut benennen kann.
Außerdem ist es dort einfacher neue Werte dazwischenzuschieben.

Der Code aus dem ersten Beitrag ist ja definitiv nur ein Beispiel, denn so wie er ist, kann er garnicht kompiliert werden.
Also dann doch alle Möglichkeiten nennen, da wir ja die tatsächlichen Daten nicht kennen und der TE muß sich dann eben selber was aussuchen.
(es gib noch mehr Varianten, aber diese laufen am Ende doch eigentlich alle wieder nur zurück, auf diese 3 Grundvarianten)

OK, abgesehn von Variante 4 und 5:
- eine Matix, wo bei jeder einzelnen Kombination die zugeförige Funktion hinterlegt/verknüpft ist.
- mehrere verschachtelte CASE


Im Prinzip ist das IF, bei diesem Beispiel dann doch nicht so schlimm.

Also mit der richtigen Klammersetzung:

Delphi-Quellcode:

if (a = 0) and (b = 0) then
  Anweisung1
else if (a = 0) and (b > 0) and (b < 10) then
  Anweisung2
else if (a = 0) and (b = 10) then
  Anweisung3
else if (a > 0) and (a < 5) and (b = 0) then
  Anweisung4
else if (a > 0 and (a < 5) and (b = 10) then
  Anweisung5
else if (a = 5) and (b = 0) then
  Anweisung6;

ein paar Zusammenfassungen:

Delphi-Quellcode:

if (a = 0) and (b = 0) then
  Anweisung1
else if (a = 0) and (b in [1..9]) then
  Anweisung2
else if (a = 0) and (b = 10) then
  Anweisung3
else if (a in [1..4]) and (b = 0) then
  Anweisung4
else if (a in [1..4]) and (b = 10) then
  Anweisung5
else if (a = 5) and (b = 0) then
  Anweisung6;

Und, wegen der Übersicht, alles gleich:

Code:

if       (a in [0   ]) and (b in [0   ]) then
  Anweisung1
else if (a in [0   ]) and (b in [1..9]) then
  Anweisung2
else if (a in [0   ]) and (b in [10  ]) then
  Anweisung3
else if (a in [1..4]) and (b in [0   ]) then
  Anweisung4
else if (a in [1..4]) and (b in [10  ]) then
  Anweisung5
else if (a in [5   ]) and (b in [0   ]) then
  Anweisung6;
{sehr praktisch, daß beim Delphi-Tag die Leerzeichen igrnoriert werden}

Die leutzten Beiden sind zwar "übersichtlich", aber vom generierten Code her natürlich nicht so optimal, aber es sollte ja nur übersichtlich sein ... was stören einen da die paar zusätzlichen Bytes und die paar zusätzlichen Microsekunden.

[Furtbichler]

Hab noch was:

Delphi-Quellcode:

Function ValueRange (Value, Min, Max : Integer) : TRangeResult;
Begin
  if Value<Min then
    Result := rrTooSmall
  else if Value>Max then
    Result := rrTooBig
  else
    Result = rrJustRight
End;

Begin
  RangeOfA := ValueRange (A,1,4);
  RangeOfB := ValueRange (B,1,9);

 case RangeOfA of
   rrTooSmall:
     case RangeOfB Of
       rrTooSmall :
         Anweisung1
       rrJustRight:
         Anweisung2
       rrTooBig:
         Anweisung3;
     end;
   rrJustRight :
     case RangeOfB Of
       rrTooSmall:
         ???
       rrJustRight:
         Anweisung4
       rrTooBig:
         Anweisung5;  
     end;
   rrTooBig :
     case RangeOfB Of
       rrTooSmall:
         Anweisung6;
       rrJustRight:
         ???
       rrTooBig:
         ???;  
     end;
end;

Das entspricht einer Entscheidungsmatrix.

Aber man sieht auch hier: Etwas Ordnung geschaffen und die Lücken werden sichtbar. Es sind nicht alle Fälle abgedeckt...

Weiterer Vorteil: Die Bereichsprüfung ist nur an einer Stelle (DRY) und somit leicht änderbar.

Wie man an die Sache herangeht, hängt natürlich mit dem konkreten Problem zusammen.

[Boyington]

Hallo alle,
danke für eure hilfsreichen Antworten:)

Noch eine Frage: wie kann ich in Delphi folgendes realisieren?

case i of
1: Anweisung1;
2..(a+b): Anweisung2;
(a+b+1): Anweisung3;

Aber es geht leider nicht, bei (a+b) und (a+b+1) muss man die Werte direkt angeben, sonst bekommt man Fehlermeldung "constant expression expected"

Gruss
Lee

[himitsu]

Garnicht.

CASE kann eben nur mit Konstanten benutzt werden, so wie es die Fehlermeldung auch besagt.
(hätte mir es auch schon manchmal anders gewünscht :cry:)

eventuell? so

Delphi-Quellcode:

case i - (a + b) of
  0: Anweisung2;
  1: Anweisung3;
//else Anweisung1;
  else if i = 1 then Anweisung1;
end;

[Boyington]

Zitat:

Zitat von himitsu (Beitrag 1173135)

Garnicht.

CASE kann eben nur mit Konstanten benutzt werden, so wie es die Fehlermeldung auch besagt.
(hätte mir es auch schon manchmal anders gewünscht :cry:)

eventuell? so

Delphi-Quellcode:

case i - (a + b) of
  0: Anweisung2;
  1: Anweisung3;
//else Anweisung1;
  else if i = 1 then Anweisung1;
end;

Danke dafür!
Gibt es vielleicht noch andere Möglichkeit bzw. Weg, um gleiche Funktionalität auch mit "case of" zu bekommen?

Gruss
Lee

[blackfin]

hilft dir da der "case true of"-Trick vielleicht, den man in C oft benutzt?
Also sowas in der Art (ungetestet):

Delphi-Quellcode:

case true of

 (a=0 and b=0):   
 begin
      
  end;

 (a>0 and a<5 and b=10):   
 begin
      
  end;

  // etc.

end;

Bin mir jetz aber nicht sicher, ob der Compiler dann nicht mit "doppeltes case label" motzt...hab sowas schon lange nicht mehr in Delphi geschrieben und kanns grad nicht testen..

[Iwo Asnet]

Geht nicht, case label müssen Konstanten sein. Dessen ungeachtet ist das kein Trick, sondern eine Zumutung ;-)

[blackfin]

Zitat:

Dessen ungeachtet ist das kein Trick, sondern eine Zumutung

hihi, ja, find ich auch, wird aber in c relativ oft verwendet, habs zumindest schon oft gesehen :D

[himitsu]

Wobei es in C ja eigentlich intern nur viele IFs sind, wo man auch noch manuell rausspringen muß, damit Nachfolgendes nicht auch noch mit ausgeführt wird.
(so wie ich das zumindestens mitbekommen hab)

[Meflin]

Zitat:

Zitat von Iwo Asnet (Beitrag 1173302)

Dessen ungeachtet ist das kein Trick, sondern eine Zumutung ;-)

Wie so ziemlich alles, was hier bisher so an Vorschlägen kam :stupid:

[Furtbichler]

Na

Zitat:

Zitat von Meflin (Beitrag 1173328)

Zitat:

Zitat von Iwo Asnet (Beitrag 1173302)

Dessen ungeachtet ist das kein Trick, sondern eine Zumutung ;-)

Wie so ziemlich alles, was hier bisher so an Vorschlägen kam :stupid:

Na dann, Größmäulchen: Belehre uns.

Wie macht man's richtig?

[Meflin]

Zitat:

Zitat von Furtbichler (Beitrag 1173365)

Na

Zitat:

Zitat von Meflin (Beitrag 1173328)

Zitat:

Zitat von Iwo Asnet (Beitrag 1173302)

Dessen ungeachtet ist das kein Trick, sondern eine Zumutung ;-)

Wie so ziemlich alles, was hier bisher so an Vorschlägen kam :stupid:

Na dann, Größmäulchen: Belehre uns.

Wie macht man's richtig?

Keine Sorge, wenn ich die Frage mit den gegebenen Infos guten Gewissens beantworten könnte, hätte ichs getan. Ich muss nur wirklich lange suchen, wann ich zuletzt auch nur ein verschachteltes if schreiben musste. Vieles löst sich eben bei durchgezogener Objektorientierung mit polymorphen Aufrufen von selbst. Blos bei der abstraktion der Frage kann ich mir da auch nichts aus den Fingern saugen.

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

[Furtbichler]

Zitat:

Zitat von Meflin (Beitrag 1173389)

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. :-D 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. :stupid:

[blackfin]

Zitat:

...Theoriefuzzi...

Made my day :D

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:

Zitat von Furtbichler (Beitrag 1173393)

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

Ach ja, das gute alte nicht-Argument. Sorry, du bist disqualifiziert :roll: (... 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:

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.