Warum macht man "if(true)"

[GilbertGrape]

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]

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]

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]

@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]

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]

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]

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]

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

 

[AlexSpritze]

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,

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]

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]

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]

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]

Quelle?

Clean Code Talks – Inheritance, Polymorphism, & Testing

zb

 

[Paddelpirat]

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]

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]

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

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

 

[SlaterB]

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]

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]

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