Else if return

Das deckt sich auch mit der Aussage von ‚Uncle Bob‘ in Clean Code. In den obigen, verschachtelten ifs würde ich es aber auch als sauberer ansehen, nur ein Statement ans Ende zu packen.

[QUOTE=Dow_Jones;140247]Aus reiner Nickeligkeit möchte ich mal sagen: Ich finde euer aller Code häßlich. :playful:

Bei mir sähe die Methode grundsätzlich so aus:

    Color color;

    if( condition ) {
        color = Color.RED;
    } else {
        color = Color.GREEN;
    }

    return color;
}

Ggf. auch mit color = condition ? Color.RED : Color.GREEN;, aber sicher nicht mit returns mittendrin. Mag man als Kindergarten-Stil bezeichnen, hat sich aber (bislang) als vollkommen streßfrei erwiesen.
:popcorn:[/QUOTE]

Das hätte ich früher auch gesagt, inzwischen sehe ich das anders. Wenn man dafür sorgt, dass Methoden kurz und prägnant sind, ist es nicht mehr so wichtig, nur ein return zu haben, wie bei 450-Zeilen-Methoden.

Und obiges enthält einfach unnötig viel Code. Daher stünde da bei mir

    if (condition) {
        return Color.RED;
    } 
    else {
        return Color.GREEN;
    }
}```

Ja, auch mit dem else. *schmunzelt*

Moin,

na tolle Wurst, dann sind wir ja genau wieder bei der Warning des allerersten Posts … :kotz:

Gruß Klaus

Bei mir warnt Eclipse deswegen nicht.

Und ich finde, dass

        if (condition) {
            return Color.RED;
        }
        return Color.GREEN;
    }```

statt

```    Color getColor(...) {
        if (condition) {
            return Color.RED;
        }
        else {
            return Color.GREEN;
        }
    }```

nur unnötig verschleiert, dass eine entweder-oder-Entscheidung getroffen wird.

Bei den komplexeren Beispielen weiter oben würde ich vermutlich auch nicht alles in den else-Teil stecken. Aber vielleicht würde ich dann ein else mit dem Aufruf einer anderen Methode verwenden, in der dann der "anderenfalls"-Teil gemacht wird.

Es kommt allerdings immer drauf an. Wenn wirklich nur vorweg etwas sichergestellt werden soll, mag es auch vorkommen, dass ich dann kein else verwende.

[quote=Crian]Bei den komplexeren Beispielen weiter oben würde ich vermutlich auch nicht alles in den else-Teil stecken. Aber vielleicht würde ich dann ein else mit dem Aufruf einer anderen Methode verwenden, in der dann der “anderenfalls”-Teil gemacht wird.

Es kommt allerdings immer drauf an. Wenn wirklich nur vorweg etwas sichergestellt werden soll, mag es auch vorkommen, dass ich dann kein else verwende.[/quote]

Ich finde eben auch, dass es einen Unterschied macht. If mit else bedeutet, dass es zwei gleichwertige Teilbereiche sind. if ohne else hat für mich eine andere Aussage z.B., dass das if nur etwas sicher stellen will, (hat also eher die Bedeutung eine Precondition)

Moin,

dann sind vermutlich diese Warnungen dann bei Dir in den Einstellungen ausgeschaltet …
Gruß Klaus

um das reaktiviere Thema noch etwas weiterzuspinnen wäre noch interessant ob jeweils

    Color c = null;
   if (x < 5)  {
        c = Color.RED;
   } else  {
       return Color.GREEN;
   }
   ..
   return c;
}

in Frage käme? also ein return im else-Fall ohne return im if?

für ‚ohne vermeidbares else‘-Fans wie mich sowieso möglichst gar nicht verwenden/ umdrehen,
wobei Eclipse (als einstellbare Warnung) aber nicht so konsequent streng ist, ein Abbruch im else standardmäßig anzumeckern,

im switch ist ja auch ein Abbruch im default-Fall erlaubt und häufig, nicht erst hinter dem switch stehend…


bei ‚mit else‘ macht Vertauschung des Codes nicht viel aus:

   Color c = null;
   if (x >= 5)  {
       return Color.GREEN;
   } else  {
       c = Color.RED;
   }
   ..
   return c;
}

dies kann genau so wünschenswert sein, ablesbar dass RED direkte Konsequenz des ifs ist

technisch macht es aber keinen Unterschied mehr zu

   Color c = null;
   if (x >= 5)  {
       return Color.GREEN;
   } else  {
       c = Color.RED;
      ..
      return c;
   }
}

als auch

   Color c = null;
   if (x >= 5)  {
      return Color.GREEN;
   }
   c = Color.RED;
   ..
   return c;
}

und da bevorzuge ich die aufgeräumteste letzte Variante


im normaleren Gebrauch ist ein if mit zwingenden return für mich eine endgültige Abzweigung,
ein else dazu würde verwirren, als wenn es dahinter noch weiter gehen könnte,

am Ende einer Methode wenig Verwirrung möglich, interessanter ist es wiederum bei innerer weiterer Verschachtelung, die evtl. gar nicht komplett zu überblicken ist
(ob allgemein zu vermeiden, kurze Methoden usw., das bekannt und außen vor gelassen, zumindest kein extra Hinweis hier nötig :wink: )

Code B von oben ist schon ein gutes Beispiel, er lässt vermuten, dass in den hinteren Teil der Methode gekommen werden kann,
ohne dass c auf RED gesetzt wird,

noch kritischer mit interner Verschachtelung:

   Color c = null;
   if (x >= 5)  {
      if (x >= 20) {
         return  return Color.GREY;
      else {
         return Color.GREEN;
      }
   }  else  {
      c = Color.RED;
   }
   ..
   return c;
}

hier ist nun nicht mehr so leicht zu erkennen, ob das erste if immer beendet wird,
weil darin das letzte return nur wieder in einer else-Verschachtelung, das innere if dazu könnte ja evtl. kein return enthalten,

besser wäre es im Falle von ‚mit else‘, wenn man Code B von oben abgelehnt und immer wie in Code C alles weitere nach einem if mit return komplett ins else steckt,
aber das kann lange else bedeuten, und etwas inkonsequent gegenüber Preconditions,

etwas konstruiertes Beispiel inzwischen, aber ein Verzicht auf else wäre hier im Einklang Preconditions und immer gleich kurz sauber übersichtlich:

   Color c = null;
   if (x >= 5)  {
      if (x >= 20) {
         return  return Color.GREY;
      }
      return Color.GREEN;
   }  
   c = Color.RED;
   ..
   return c;
}

der hintere Teil inklusive der RED-Zuweisung steht auf unterster Ebene,
falls Methode bis hierhin kommt, nicht vorher abgebrochen wird, dann hier ganz normale garantierte Ausführung aller Befehle, kein Verschachtelung zu bedenken,

davor steht ein if (x >= 5), welches einmal betreten immer zum Ende der Methode führt,
wie durch das return am Ende des ifs so gut wie eben möglich dargestellt wird,

dass im Inneren des ifs weitere Verzeigung besteht muss man in erster Linie gar nicht anschauen,
wenn dann gleiches Bild: ein inneres if mit garantierten Abbruch vorhanden