Was ist die saubere Form bei einem if-statement ohne else?

Die Frage ist recht simpel. Was ist die saubere Form eines if-statements ohne else?

Was ich normalerweise machen würde, wäre das:

if("Bedingung") { 
    "mach etwas"
}

Aber ich habe von einem Freund gehört, dass das nicht die saubere Variante davon wäre. Besser wäre, wenn man am Ende else hinschreibt ohne dass es etwas macht:

if("Bedingung") { 
    "mach etwas"
} else {
    
}

Was ich auch schon mal gesehen habe, ist die 2 Variante mit einem return im else

if("Bedingung") { 
    "mach etwas"
} else {
    return;
}

Was wäre "offiziell" die richtige Variante?

Cheers
Luke

Answer 1

[Omnivore11]

Es gibt keine "offizielle" richtige Antwort.

Variante 1 ist vollkommen korrekt.

Variante 2 ist sinnfrei, weil er dann auf Assembler-Ebene einen weiteren Sprungbefehl macht und wieder zurück. Die meisten Compiler würden das aber eh nicht übersetzen und es wäre im Endeffekt deckungsgleich mit Variante 1

Variante 3 ist komplett falsch. Denn wenn ich jedes mal beim else Fall aus der Methode springe, kann der ganze Kode verhunzt werden.

Beispiel:

for(i=0 ; i<=100 ; i++)
  if(i%10=0) System.Console.WriteLine(i.ToString());

Ein leerer else Zweig wäre sinnlos und trägt nur dazu bei, dass es nur noch unübersichtlicher wird.

Variante 3 würde das ganze Programm nicht zu dem bewegen, was es eigentlich soll. Bei i==1 ist das Programm beendet.

Dein Freund sollte sich mehr mit Programmieren beschäftigen.

Gruß
Omni

Comments

[Omnivore11]

Danke für den Stern!

Answer 2

[ceevee]

Die erste Variante... hat zumindest in meinem Berufsleben immer gereicht. Das unnötige leere "else" in der zweiten Variante macht den Quelltext nur unnötig länger und schwerer zu lesen, außerdem würde jeder Compiler das eh rausoptimieren. Die dritte Variante macht sogar etwas anderes als die erste, das "return" würde eine Funktion beenden und der Code, der hinter der Verzweigung steckt, würde dann nciht erreicht werden.

Comments

[androhecker]

Funktion ist ein ganz böses Wort in Java

[ceevee]

@androhecker

Naja, es sagt ja keiner, dass sich der Fragesteller auf Java bezieht. Für Methoden gilt aber das selbe. :)

[androhecker]

Komisch, da steht gar nicht Java in den Tags und ich bekomme die Frage in der Liste, fail.

Answer 3

[Schachpapa]

Die ersten beiden Formen sind gleichwertig, wobei ein leerer else-Block "unschön" ist.

Die dritte Version ist etwas anderes. In einer Methode oder Funktion bedeutet return sofortige Beendigung. D.h. wenn nach der Fallunterscheidung noch Anweisungen kommen, würden die nur im Ja-Fall ausgeführt.

void methode() {
 if("Bedingung") { 
 "mach etwas" 
 } else {
 return;
 }
 mach noch mehr;
}

D.h. dieses Beispiel verhält sich genauso, als wenn "mach noch mehr" im Ja-Zweig stünde. Da das nicht so ist, hat sich er Programmierer vielleicht etwas dabei gedacht und falsch gedacht.

Generell: Vorsicht mit return, wenn es nicht am Ende einer Methode steht. Es sei denn, du weißt genau was du tust.

Answer 4

[TeeTier]

Neben den bisherigen Antworten noch eine kurze Anmerkung:

Bei der sog. defensiven Programmierung ist man manchmal durch Projekt-Richtlinien dazu gezwungen, die zweite Variante zu verwenden. Das gilt für extrem kritische Anwendungsfälle, wie z. B. Banksysteme oder Flugzeuge.

Und zwar wird mit dem leeren else-Zweig direkt gezeigt, dass der Entwickler sich zu 100% bewusst dazu entschlossen hat, an dieser Stelle nichts zu tun. Es kann also ausgeschlossen werden, dass etwas vergessen wurde.

Über die Sinnhaftigkeit davon kann man durchaus länger diskutieren, und ich mache hier dazu selbst auch keine Aussage, sondern weise nur darauf hin.

In extremerer Form gibt es das auch noch bei switch-Konstrukten, wo sogar bei "normaler" Anwendung in nicht-kritischen Bereichen oft empfohlen wird, ausnahmslos immer einen default-Zweig einzubauen. Dem schließe ich mich auch (fast) immer an. :)

Aber um bei deiner Frage zu bleiben: Natürlich ist die erste Variante am sinnvollsten und erstrebenswert. Der leere else-Zweig in der zweiten Variante wird sowieso vom Compiler wegoptimiert werden, sodass der resultierende Maschinencode sowieso identisch mit dem, der ersten Variante ist.

Darauf, dass die dritte Möglichkeit gefährlich und fast immer sogar falsch sein wird, wurde ja schon an anderer Stelle schon gesagt.

Schönen Abend noch! :)

Answer 5

[androhecker]

Beim ersten ist das Else komplett nutzlos und muss weg, beim zweiten Beispiel ist das ein großer Unterschied, das Return beendet die Methode.

Comments

[TeeTier]

Dein Profilbild gefällt mir, aber enthält zwei kleine Knickeier:

• Der Prompt "$" suggeriert einen unpreviligierten User-Account, nimm stattdessen lieber "#" für root.
• Das Sternchen löscht NUR alle nicht-versteckten Dateien und Verzeichnisse ab dem aktuellen Verzeichnis. Da du aber das komplette Dateisystem von GF plattmachen willst, und dich vermutlich in "/home/root" oder "/root" befindest, nimm lieber ein "/" um wirklich Dateisystemübergreifend löschen zu können. Wenn du Glück hast, kommst du darüber auch in "/proc" und "/dev" um bestimmte Teile eines UEFI-Bios zu zerstören. Dabei werden dann auch versteckte Dateien und Verzeichnisse berücksichtigt.

Zusammenfassend ist folgende Lösung also besser:

[e-mail]# rm -rf /

Viel Spaß noch bei dem, was auch immer du tust! :)

[androhecker]

Stimmt, habe mir beim Erstellen nicht so viel gedacht, sollte ich mal verbessern.