case .. of kann kein break - Gibt es dafür einen rationalen Grund?

[TSchnuckenbock]

Rollo62 sprach ja in Beitrag #4 von "Antipattern". Da dachte, schau mal nach....

https://de.wikipedia.org/wiki/Anti-Pattern

Für den Nachmittag vorm Feiertag vielleicht genau richtig zum Lesen.

Das "Antipattern", am Anfang einer Methode mit if-then und einem exit dann rauszuspringen setze ich übrigens auch gerne ein.

Zum Thema: Ein break im Case-Konstrukt habe ich noch nie vermisst.

[Rollo62]

Allerdings, schöne zusammengefasst auf der Seite.

Zitat von TSchnuckenbock:

Das "Antipattern", am Anfang einer Methode mit if-then und einem exit dann rauszuspringen setze ich übrigens auch gerne ein.

Da bin ich mittlerweile ganz anderer Meinung.
Denn ich nutze das "GUARD" Pattern sehr ausgiebig, was ich auch mit "negative Logic" benenne.
Also statt immer nur bei positiv ins nächste if-then verzweigen, erzeugt oft sehr unübersichtliche Strukturen.

Während ein "GUARD" mit "negativer Logik" am Anfang einer Methode diese sicher absichert und
im Folgenden die eigentlich wichtigen Abläufe sehr sauber darstellt.

Das habe ich zum Beispiel auch in anderen Sprachen sehr positiv wahrgenommen, dass dies die Methoden ordentlich aufräumen kann.

Am Besten mal selber eine zeitlang ausprobieren, denn der positive Effekt stellt sich schnell ein.

Nicht alle "AntiPattern" müssen direkt immer in der Hölle enden

[himitsu]

außen ein Try-Except drumrum und dann ABORT statt BREAK.

[Rollo62]

Zitat von himitsu:

außen ein Try-Except drumrum und dann ABORT statt BREAK.

Jesus H. Christ

[Jasocul]

Warum seid ihr so versessen auf diese Guard am Anfang einer Methode?
Entweder es ist eine einfache Prüfung, dann hat man höchstens eine Ebene mehr in der Verschachtelung oder es sind viele Prüfungen erforderlich, dann macht man eine Function davon und hat wieder nur eine Ebene mehr. Ich habe dieses Anti-Pattern noch nie gebraucht und ich halte meinen Code für sehr gut lesbar. Meine Kollegen haben sich zumindest noch nie darüber beschwert und ich bezweifle, dass die Angst vor mir haben.

Zum Break im Case:
Das ist Delphi/Pascal und nicht C. Niklaus Wirth hat es so definiert. Dass es auch anders geht, steht außer Frage. Ich sehe aber keinen ernsthaften Grund, warum das notwendig sein sollte. Da gibt es andere Einschränkungen im Case, die mich mehr nerven. Z.B. die Beschränkung auf ordinale Typen.

[himitsu]

Wobei das auch schon im Basic so war (ohne Break), sowie auch COBOL (außer dass dort das CASE noch EVALUATE hieß), Algol und anderen Delphi/Pascal-Vorfahren.
Also eigentlich war es garnicht seine Idee.

Joar, Strings wären auch mal was.

Delphi-Quellcode:

uses System.StrUtils, Vcl.Dialogs;
type TTheCase = (blubb, blob, wuppdi);
const cTheCase: array[TTheCase] of string = ('blubb', 'blob', 'wuppdi');

procedure TForm1.FormCreate(Sender: TObject);
begin
  var S := InputBox(Application.Title, 'Was: ' + string.join(' ', cTheCase), 'mähhh');
  case TTheCase(IndexStr(S, cTheCase)) of
    blubb, blob: ShowMessage('Juhu: ' + S);
    wuppdi: ShowMessage('Hihooo: ' + S);
    else ShowMessage('Nööö: ' + S)
  end;
end;

[Rollo62]

Zitat von Jasocul:

Entweder es ist eine einfache Prüfung, dann hat man höchstens eine Ebene mehr in der Verschachtelung oder es sind viele Prüfungen erforderlich, ...

Wenn man meint es sei nur Versessenheit, dass man zwischen "einfach" und "komplex" auch noch mögliche Zwischenstufen sieht und ich mir dieses sogenannte "AntiPattern" einfach dafür offen halte,
dann kann ich ja genauso mit "Versessenheit" argumentieren, wenn man das ums Verrecken niemals nicht benutzen will

Ob Du die Komplexität nun hinter Funktionen versteckst, oder nicht, das Ergebnis bleibt das Gleiche.
Jedenfalls sehe ich durch negative Logik eine deutliche Verbesserung der Lesbarkeit und Code-Verständlichkeit, als wenn ich erst in zig Funktionen reinspringen und nachsehen müsste.

[Jasocul]

Zitat von Rollo62:

Ob Du die Komplexität nun hinter Funktionen versteckst, oder nicht, das Ergebnis bleibt das Gleiche.

Völlig korrekt, aber mit dem Argument könnte man auch rechtfertigen, dass man Variablen einfach durchnummerieren kann oder jede Form von Styleguide ignorieren.

Zitat von Rollo62:

Jedenfalls sehe ich durch negative Logik eine deutliche Verbesserung der Lesbarkeit und Code-Verständlichkeit, als wenn ich erst in zig Funktionen reinspringen und nachsehen müsste.

Und ich sehe in einer Guard eine deutliche Verschlechterung der Lesbarkeit. Insbesondere, wenn dieser ein paar Zeilen der eigentlichen Prozedur wegnimmt, bevor man zum wesentlichen Code kommt. Ich habe leider schon Gurads gesehen, die über 20 Zeilen lang waren.
Wenn man für die Verständlichkeit in die Funktionen reinspringen muss, dann sollte man vielleicht eher darüber nachdenken, den Funktionen einen brauchbaren Namen zu geben. Ich schaue in diese Funktionen übrigens nur rein, wenn etwas nicht funktioniert.

Aber ich denke, dass man hier durchaus unterschiedlicher Meinung sein darf. Mein Code wird halt anders aussehen, als deiner