# Warum macht man "if(true)"



## GilbertGrape (27. Sep 2012)

Hallo,

eigentlich ist es keine java-spezifische Frage, aber egal.

Ich versuche gerade, mittels Sonar, unsere Entwickler ein bißchen für Software-Qualität zu sensibilisieren.

Dabei bin ich auf eine Violation gestoßen, die nicht selten auftritt, nämlich: "Unconditional If Statement"
Also einfach sowas hier:


```
if (true){
blabla
}
```

Es gibt ja einige Dinge, die man nicht machen soll, bei denen ich aber verstehe warum das gemacht wurde, aber bei diesem irgendwie gar nicht.

Warum macht man sowas? Das soll jetzt nicht irgendwie verurteilen oder so, ich möchte das einfach nur mal wissen.

Gruß
GilbertGrape


----------



## Firephoenix (27. Sep 2012)

Ich könnte mir vorstellen, das sowas entsteht wenn man aufräumt und irgendwann den Fall hat das die Bedingung immer eintritt und sie irgendwann durch true ersetzt.
Da

```
if (true){
blabla
}
```
aber äquivalent ist zu

```
blabla
```
 (zumindest solange sich die semantik von true nicht ändert - was aber wohl eher unwahrscheinlich ist),
gehört das einfach aus dem Code rausgeräumt, das sind 2 Zeilen Altlast die beim Arbeiten stören.

Gruß


----------



## Tomate_Salat (27. Sep 2012)

Ich schreibe solche Konstrukte manchmal für Entwicklungs-/Testcode der eine bestehende Methode erweitert [aber eigentl. nur dann, wenn diese eine längere Ausführungszeit hat]. Dann schaut das aber i.d.R so aus:

```
if(true) { // wobei ich hier meistens true durch eine Variable ersetze, die true ist und ggf als Schalter funktionieren kann.
  //... code der ausgeführt werden soll
  return;
}

// ... code der i.d.R lange zum ausführen braucht und somit das Testen stört.
```

Wenn aber der Code in der Bedingung fertig und funktionsfähig ist, entferne ich das if-konstrukt.


----------



## Firephoenix (27. Sep 2012)

@Tomate_Salat
ohne eine ausgelagerte variable wie z.b. 

```
public static final boolean REMOVE_AFTER_TESTS = true;
```

und dann

```
if(REMOVE_AFTER_TESTS){
//...
return;
}
```

sähe das aber ziemlich gefährlich aus, zumindest wenn man das mal in 3 Methoden gleichzeitig macht und dann eine vergisst wenn man fertig ist mit Testen 

Gruß


----------



## parabool (27. Sep 2012)

weiterer Grund:
Wenn du eine Methode vorzeitig mittels return verlassen willst (beim Testen, um irgendwas nach dem return auszublenden)

if(true)return;

ansonsten Fehler: Unreachable code

Edit: Tomate_Salat hats schon geschrieben


----------



## Marco13 (27. Sep 2012)

Das ist eine Möglichkeit zum schnellen Ein/Ausschalten von blocks - entsprechend einem #ifdef in C. Ein "echtes" Auskommentieren kann unerwünschte Folgen haben (/* Nested  /* comments */ */, "unused variable"-Warnungen, "unreachable statement"-Fehler). Ich bevorzuge für sowas aber eher

```
boolean doSomeDebuggingTest = false;
doSomeDebuggingTest = true;
if (doSomeDebuggingTest) 
{
....
}
```
weil man dann erstens "den Block benennen" kann (ah, das ist ein debugging-Test), und zweitens durch ein/auskommentieren einer einzigen Zeile den Block ein/ausschalten kann. 

Wie das Beispiel aber schon zeigt verwende ich das in erster Linie für debugging-Tests oder sehr spezielle (z.B. experimentelle oder verläufige) Teile, und wenn sowas exzessiv in "Production Code" auftaucht wäre das schon suspekt...


----------



## SlaterB (27. Sep 2012)

für Normalcode fällt mir nichts ein, aber das Beispiel von Tomate_Salat möchte ich auch bekräftigen,

ein einfaches return;, wenn man mal einen anderen Ablauf haben will, gibt Compilerfehler mit Code dahinter,
if (true) ist nette Möglichkeit das doch zu erlauben, 

könnte der Compiler eigentlich auch erkennen, hinter
while(true) {}
läßt er schließlich auch keinen Code zu,
und if (true) mit return drin kann genausowenig danach noch fortgesetzt werden,
und normales return erkennt der Compiler ja auch und und und


----------



## GilbertGrape (27. Sep 2012)

Ah alles klar, um den Compiler-Fehler zu umgehen.


----------



## AlexSpritze (27. Sep 2012)

SlaterB hat gesagt.:


> für Normalcode fällt mir nichts ein, aber das Beispiel von Tomate_Salat möchte ich auch bekräftigen,
> 
> ein einfaches return;, wenn man mal einen anderen Ablauf haben will, gibt Compilerfehler mit Code dahinter,
> if (true) ist nette Möglichkeit das doch zu erlauben,
> ...



Weiß jemand, wieso der Compiler hinter dem if kein unreachable Code sieht, hinter dem while aber schon? Das ist mir schon häufiger aufgefallen, aber ich kann es mir nicht erklären.


----------



## Paddelpirat (27. Sep 2012)

AlexSpritze hat gesagt.:


> Weiß jemand, wieso der Compiler hinter dem if kein unreachable Code sieht, hinter dem while aber schon? Das ist mir schon häufiger aufgefallen, aber ich kann es mir nicht erklären.



Weil die Bedingung für das if nur einmal abgefragt wird und man bei while(true) eine endlosschleife hat.
bei if(true) ist der Code dahinter ja nur nicht mehr erreichbar, wenn in dem if-Block ein return steht.


----------



## Rudolf (27. Sep 2012)

Man sollte bei Sprachen, die Polymorphismus unterstützen, auf Conditionals wie möglich verzichten, boolean gehören dazu. 

Außerdem kenne ich eine if(true)-Kondition, wenn Code generiert wird. Irgendwann ändert sich der Generatorcode und dann ist es am einfachsten eine Condition durch if(true) zu ersetzen.


----------



## AlexSpritze (27. Sep 2012)

Paddelpirat hat gesagt.:


> Weil die Bedingung für das if nur einmal abgefragt wird und man bei while(true) eine endlosschleife hat.
> bei if(true) ist der Code dahinter ja nur nicht mehr erreichbar, wenn in dem if-Block ein return steht.



Ich hätte es expliziter schreiben sollen:


```
if(true) {
return;
}
System.out.println("Never to be executed?");
```


```
while(true) {
}
System.err.println("Never to be executed!");
```




> Man sollte bei Sprachen, die Polymorphismus unterstützen, auf Conditionals wie möglich verzichten, boolean gehören dazu.


Quelle?


----------



## bygones (27. Sep 2012)

AlexSpritze hat gesagt.:


> Quelle?


Clean Code Talks – Inheritance, Polymorphism, & Testing 

zb


----------



## Paddelpirat (27. Sep 2012)

AlexSpritze hat gesagt.:


> Ich hätte es expliziter schreiben sollen:



Ah okay, in dem Fall würde ich mal raten, dass es damit zu tun hat, dass du aus dem while(true) von selbst nicht raus kommst, während sich dein Programm durch das if(true) return nicht aufhängt, sondern nur einen anderen Rückgabewert liefert.


----------



## AlexSpritze (27. Sep 2012)

Paddelpirat hat gesagt.:


> Ah okay, in dem Fall würde ich mal raten, dass es damit zu tun hat, dass du aus dem while(true) von selbst nicht raus kommst, während sich dein Programm durch das if(true) return nicht aufhängt, sondern nur einen anderen Rückgabewert liefert.



Trotzdem hängt hinter beiden Konstrukten "Unreachable code" von daher verstehe ich nicht, wieso das bei 
	
	
	
	





```
if
```
okeh ist aber bei 
	
	
	
	





```
while
```
einen Fehler beim Kompilierer auslöst.

Egal was ich hinter 
	
	
	
	





```
if(true)return;
```
 schreibe, das wird nie ausgeführt...


----------



## Tomate_Salat (27. Sep 2012)

AlexSpritze hat gesagt.:


> Egal was ich hinter if(true)return; schreibe, das wird nie ausgeführt...




```
try {
  if(true) return;
} finally {
  System.out.println("Ätsch, doch!");
}
```


----------



## SlaterB (27. Sep 2012)

hier noch ein Beispiel

```
methodA() {
   if(true) return;
}

methodB() {
   // Code weiter hinten in der Datei
}
```

"hinter if" ist schon sehr genau belegt, im gleichen Block, ohne solche Spielereien

edit:
ok, hätte Scherz auch für sich stehen lassen..,
lese zu oft tatsächliches Besserwissen


----------



## nillehammer (27. Sep 2012)

Noch mal zur Ursprungsfrage: Möglicherweise handelt es sich auch um den kläglichen Rest von "conditional compiling" Mit sonem Konstrukt hier kann man nämlich dafür sorgen, dass Quellcode nicht oder eben doch (je nach dem ob true oder false)  im Bytecode auftaucht:

```
static final boolean COMPILE= true;

if(COMPILE) {
  // do sth.
}
```
So ein Konstrukt funktioniert mit Konstanten (also static final). Wahrscheinlich hat ein Entwickler das Konstrukt nicht verstanden und daraus ein 
	
	
	
	





```
if(true)
```
 gemacht. Könnte man über eine Versionshistorie in Eurem Quellcode-Repo nachvollziehen.


----------



## xehpuk (27. Sep 2012)

nillehammer hat gesagt.:


> Mit sonem Konstrukt hier kann man nämlich dafür sorgen, dass Quellcode nicht oder eben doch (je nach dem ob true oder false) im Bytecode auftaucht:


Das ist vom Compiler abhängig.

Hier offiziell aus der JLS (ganz unten die bereits genannte Begründung): Chapter 14. Blocks and Statements


----------

