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

[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

[himitsu]

du darfst auch gern eine $REGION drumrummachen, dann isses nur eine Zeile und du siehst auch ab wo der eigentliche Code beginnt.

[Rollo62]

Zitat von Jasocul:

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

Ja das sehe ich auch so, ich verstehe ja auch all die Argumente für und wider.
Nur werden oft die Argumente wider nicht immer ernsthaft beleuchtet, das finde ich etwas schade.

Ich sehe insbesondere, dass es vielleicht Problemstellungen geben kann, die nicht immer nur die "reine Lehre" nach Schema F erforderlich machen.
Was ich zum Beispiel meine ist, dass wenn Du meistens mit festen, schön separierbaren Algorithmen arbeiten kanst,
diese zu 100% wasserdicht und vorhersagbar austesten kannst, dann bin ich ja voll und ganz auf deiner Seite.

Es gibt aber aus meiner Sicht auch viele Anwendungen die von sehr vielen Parametern und sehr stark von völlig unvorhersagbaren Ereignissen beeinflusst werden kann, insbesondere duch externe Hardware, Systemereignisse oder auf verschiedenen Plattformen usw.
Wie zum Beispiel, gerade war ein Sensor noch ansprechbar und in der nächsten Millisekunde ist der komplett weggegrätscht.
An diesen Fragestellungen befinde ich mich leider oft und da mache ich lieber einen Guard mehr als zu wenig, egal was Andere darüber denken.
Lieber safe than sorry

[Uwe Raabe]

Ein Variation des Guard-Patterns, welches im Wesentlichen beide Ansätze kombiniert, ist die Teilung in eine guarded und eine unguarded Methode. Die guarded Methode enthält dann ausschließlich die Guards gefolgt von einem Aufruf der unguarded Methode (je nach Geschmack am Schluss oder in einem mehr oder minder komplexen if ). Damit ersetzt die guarded Methode die Auslagerung der Guards in eine separate Funktion. Mit der unguarded Methode erhält man aber zusätzlich eine performantere Möglichkeit für die Fälle, bei denen die Validität der Parameter bereits geprüft oder anderweitig sichergestellt ist.

Eine separate Guard-Funktion ist aber in jedem Fall eine Überlegung wert, wenn Parameter-Sätze an mehreren Stellen auf die gleiche Validität geprüft werden.