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

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