Slide "Best practices comparing for equality"





  • Unter "See detailed explanation." ist leider nur eine Aussage hinterlegt die keinem erklärt warum man das nun so machen soll. Das sich dahinter mehr verbirgt wird nicht klar und man kann nicht verstehen wie Sie nun zu dieser Schreibweise kommen. Es wäre sehr Hilfreich hier entweder mehr Informationen bereit zu stellen oder einfach einen Link (https://en.wikipedia.org/wiki/Yoda_conditions) zu hinterlegen.



  • Und wieso empfehlen Sie überhaupt Yoda Conditions zu verwenden?! Meiner Meinung nach gibt es heutzutage keine Rechtfertigung mehr seinen Code so zu schreiben. Die Nachteile überwiegen die (kaum existierenden) Vorteile bei weitem. Yoda Conditions machen den Code nur unleserlich und unnötig schwer zu verstehen. Inzwischen gibt es aber nichts wichtigeres als einen verständlichen und gut leserlichen Code zu schreiben.
    Und Außerdem benutz heutzutage jeder eine IDE die einen auf solche Fehler hinweißt, was den Vorteil einer Yoda Condition nichtig macht.

    Korrigieren Sie mich gerne falls ich falsch liege oder erklären Sie mir wieso man Yoda Conditions verwenden sollte. 🙂



  • Der Grund liegt in Sprachen, welche ganzzahlige Ausdrücke logisch bewerten. Wir betrachten ein »C« Beispiel:

    int a = 4;
    
    /* Einige Zeilen später */
    
    if (a == 4) {
      printf("Block wurde erreicht");
    }
    

    Durch Weglassen eines der beiden Gleichheitszeichen erhalten wir eine Zuweisung:

    ...
    if (a = 4) {
      printf("Block wurde erreicht");
    }
    

    In realem Code wäre dies mit sehr hoher Warscheinlichkeit ein unbeabsichtigter Fehler. In Java ist dies auch ein Syntaxfehler, weil der Ausdruck a = 4 vom Typ her ein int und kein boolean ist. In der (sehr weit verbreitete) Sprache »C« hingegen handelt es sich um völlig legalen Code: Ein int Wert von »0« wird als logisch falsch und alle von »0« verschiedenen Werte als logisch wahr interpretiert.

    Wenn man Glück hat, ist eine Compiler Option aktiv, welche zumindest eine Warnung erzeugt. Raten Sie mal, was viele erfahrene EntwicklerInnen trotz besseren Wissens im Arbeitsalltag früher oder später ignorieren. Und raten Sie mal, welche Optionen irgendwann abgestellt werden, weil sie im Standardfall scheinbar nur nerven, aber keinen Gewinn bringen.

    Bei Umkehrung des Ausdrucks erhalten wir:

    if (4 = a) { ...
    

    Dies ist nun auch in »C« ein Compile-time Fehler, denn man kann einem Literal keinen Wert zuweisen. Auf genau diesen Punkt wird übrigens in dem von Herrn Feurer genannten Wikipedia Artikel hingewiesen.

    (Gute) IDEs sind für die praktische Softwareentwicklung entscheidend. Man sollte aber nicht fehleranfällige Coding Standards auf Sprachebene durch die Wahl einer IDE in der Hoffnung auf »scharfe« Warneinstellungen kompensieren. Zum einen sind längst nicht alle IDE's gut und zum anderen neigen Programmierer zur Deaktivierung von Warneinstellungen, s.o. , weil sie sich durch Selbige gegängelt fühlen.

    Ich wäre im Übrigen vorsichtig mit Allgemeinplätzen wie »Yoda Conditions machen den Code nur unleserlich und unnötig schwer zu verstehen«. Zunächst einmal ist dies wahlweise Geschmackssache bzw. eine durch keinerlei Umfragen, statistische Analysen von Fehlerhäufigkeiten etc. belegte Behauptung. Auch der verlinkte Artikel gibt keinerlei Belege für die ausgesprochene These. Auf »Stackoverflow« fällt dies in die Kategorie »opinionated«.



  • Vielen Dank für Ihre Antwort,
    letzten Endes ist es, wie bei wohl so vielen Dingen, Geschmackssache ob man es mag oder nicht.
    Zudem meiner Meinung nach: Jeder der freiwillig Hilfestellungen ignoriert oder diese ausschält muss halt dann auch mehr denken.

    Mir war sehr wohl bekannt, dass dies in C ein Problem darstellt und ich sehe auch, dass es dort Sinn ergibt dies zu verwenden. In Java hingegen sehe ich (bisher) keinen guten Grund dafür.



  • @Held Ja, auf Java bezogen haben Sie Recht. Mein Gedanke bezog sich darauf, dass viele MI Studierende irgendwann intensiv in C++ (Game Development) implementieren und da dachte ich, es schadet ja nicht, zumindest eine der vielen Fallen zu vermeiden. Es wäre interessant zu wissen, was unser C++ Guru Stefan Radicke dazu denkt.

    Unabhängig davon habe ich das Skript jetzt entsprechend ergänzt. In der Folie taucht ein verweisender Bulletpoint auf, in der HTML Ansicht die Erläuterung. Der vorherige Verweis sollte eigentlich ein anderes Ziel haben, ich weiß aber nicht mehr, wann selbiges verloren gegangen ist. 😕


Log in to reply