yoda style deaktivieren

[staabm]

ich bin mittlweile kein fan mehr von yoda style.

die lesbarkeit des codes leidet in meinen augen, da man "rückwärts lesen" muss und das argument bzgl. dass man durch konstante zuerst keinen fehler in der variable machen kann hat für mich in der realität noch nie funktioniert.

d.h. ich wäre dafür yoda style hier zu deaktivieren, bzw. sogar wenn möglich sogar umgekehrt dass wenn yoda style notiert wird, diesen auf die "natürlichere form" umzuformatieren

meinungen dazu?

https://cs.symfony.com/doc/rules/control_structure/yoda_style.html

[gharlan]

das argument bzgl. dass man durch konstante zuerst keinen fehler in der variable machen kann hat für mich in der realität noch nie funktioniert.

Auch wenn das wahrscheinlich mal die ursprüngliche Begründung für die Entstehung des Yoda-Styles war, war es für mich nie die ausschlaggebende Begründung.

Sondern ich nutze Yoda-Style aufgrund der besseren Lesbarkeit. Wie wir an dem Ticket hier sehen, ist das allerdings subjektiv.
Ich kann den Code dadurch schneller erfassen.

---

Wenn ich mir diesen Commit anschaue, finde ich eigentlich fast alle Stellen mit Yoda-Style besser lesbar, nur die Stellen mit > nicht. Wobei wir bei größer/kleiner auch keinen Yoda-Style erfordern.

Ich greife mal drei Beispiele aus dem Commit heraus:

-    if (false !== strpos($error['message'], 'Failed to match all schemas')) {
+    if (strpos($error['message'], 'Failed to match all schemas') !== false) {

Mit Yoda sehe ich sofort als Erstes, dass es ein "strpos ungleich false"-Vergleich ist, weil die Zeile damit beginnt.
Ohne Yoda brauche ich dafür länger, weil ich sehen muss, wo der strpos-Aufruf endet, und was dann als Vergleich folgt.

-    if (false === rex_file::put($configPath, $configFileContent)) {
+    if (rex_file::put($configPath, $configFileContent) === false) {

Ohne Yoda könnte ich am Zeilenanfang noch denken, es wäre ein positiver Check.
Mit Yoda sehe ich sofort, dass rex_file::put auf false geprüft wird.

-        if (1 === count($parameterAcceptors) && $this->isSafeType($parameterAcceptors[0]->getReturnType())) {
+        if (count($parameterAcceptors) === 1 && $this->isSafeType($parameterAcceptors[0]->getReturnType())) {

Mit Yoda sehe ich sofort, dass es mit einem "count gleich 1"-Check losgeht.
Ohne Yoda muss ich erst finden, bis wo der count-Aufruf geht, und dort die 1 finden.

---

Hinzu kommt noch, dass man weniger aufpassen muss bzgl. Klammerung:

-    if (false !== $pos = strpos(...))
+    if (($pos = strpos(...)) !== false)

---

Mich überzeugt hingegen das "rückwärts lesen"-Argument nicht. Man liest ja nicht den Source-Code wie einen Satz, Wort für Wort. Sondern man wirft zunächst einen groben Blick drauf, und versucht die Grund-Struktur zu erfassen. Und blickt dann immer mehr in die Detailtiefen.
Aus meiner Sicht liest man den Code also eher Baum-artig. Und da hilft mir der Yoda-Style, um erst mal grob zu erkennen "ah, ein count gleich 1"-Check, und dann kann ich ggf. in die Tiefe gehen, was dort eigentlich gezählt wird etc.

[staabm]

Mich überzeugt hingegen das "rückwärts lesen"-Argument nicht. Man liest ja nicht den Source-Code wie einen Satz, Wort für Wort.

ich denke dass man - insbesondere als jemand der yoda style noch nicht kennt - instinktiv den code schreibt wie einen satz und in der reihenfolge wie man es sich denkt.

insbesondere im redaxo umfeld schätze ich den anteil an leuten die weniger abstrakt programmierende entwickler sind dazu als sehr hoch ein.

aber wie du es richtig sagst sind beide ansichten geschmacksache. wir haben auch kürzlich in der firma yoda style wieder deaktiviert und dabei habe ich entdeckt dass es für mich nach jahrelangsam yoda-style=aktiv eine sehr angenehme erfahrung war/ist.

[christophboecker]

Wenn ich auch noch meinen Senf dazugeben darf ...

Ich habe mich ganz gut an den Yoda-Style gewöhnt und empfinde den Nutzen ähnlich wie Gregor. Zu 95% passt es für mich, aber manche Sachen sind konsequent geyodat wenig eingängig. Z.B.

if (1 < $x && $x < 17) ...

ist im Yoda-Style m.E. schlechter lesbar:

 if (1 < $x && 17 > $x) ...

Aber das sind so die gefühlten Ausnahmen.

[gharlan]

Wobei wir es daher an solchen Stellen (größer/kleiner) auch nicht erfordern. nur bei (un)gleicheits-checks.