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

[Rollo62]

Abschliessend vielleicht noch was ChatGPT dazu sagt:

Zitat:

- Philosophie von Strukturierter Programmierung: Pascal wurde mit einem starken Fokus auf strukturierte Programmierung und Einfachheit im Design entwickelt. Wirth wollte eine Sprache schaffen, die leicht zu lehren und zu verstehen ist, insbesondere für Studenten und Entwickler, die sich auf die Algorithmen und nicht auf komplexe Sprachkonstrukte konzentrieren sollen. Die case-Anweisung wurde so entworfen, dass sie klar und unmissverständlich ist, ohne die Möglichkeit für unerwartete Sprünge oder das Verlassen von Anweisungsblöcken, die zu schlecht lesbarem Code führen könnten.

Vermeidung von Kontrollfluss-Komplexität: Die break-Anweisung in Sprachen wie C erlaubt es, den normalen Fluss einer Schleife oder eines Schalters (Switch) abrupt zu unterbrechen. Dies kann zu "Spaghetti-Code" führen, bei dem der Kontrollfluss schwer nachzuvollziehen ist. Indem Pascal diese Option ausschließt, fördert es eine klarere, linearere Codestruktur.

Geschichtliche Entwicklung: Zur Zeit der Entwicklung von Pascal gab es bereits andere Programmiersprachen wie ALGOL, die ähnliche Kontrollstrukturen ohne break nutzten. Wirths Entscheidung, break nicht zu implementieren, reflektiert möglicherweise auch eine Präferenz für die strengeren Kontrollflusskonzepte von ALGOL.

Fehlervermeidung: Durch das Fehlen einer break-Anweisung werden Fehler vermieden, die durch das versehentliche Überspringen des Rests eines Schaltblocks entstehen könnten, was in komplexen Switch-Anweisungen in C häufig Probleme verursacht.

Wurde im Prinzip ja alles schon gesagt, hier nochmal schön zusammengefasst.

[Uwe Raabe]

Zitat von Rollo62:

ich hatte ja schon erklärt, dass ich gerne Guards einsetze,
statt tiefverschachtelter, unübersichtlicher if-then-else.

In dem Fall könnte man den Code der jeweiligen case-labels in separate Methoden oder lokale Prozeduren auslagern. Dort kannst du dann problemlos die Guards einsetzen.

[Rollo62]

Zitat von Uwe Raabe:

Zitat von Rollo62:

ich hatte ja schon erklärt, dass ich gerne Guards einsetze,
statt tiefverschachtelter, unübersichtlicher if-then-else.

In dem Fall könnte man den Code der jeweiligen case-labels in separate Methoden oder lokale Prozeduren auslagern. Dort kannst du dann problemlos die Guards einsetzen.

Zitat:

Wahrscheinlich macht es dann sowieso Sinn statt "begin end;" im case zu haben, besser eine spezifische Case-Funktion aufzurufen.

Das meinte ich, war vermutlich zu sperrig formuliert

[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.