2013-06-13 28 views
5

Mój IDE (IntelliJ IDEA) mówi mi, że mam możliwość usunięcia szelki na ten if:Czy należy unikać wielu instrukcji if, takich jak "if (warunek) if (warunek) ..." w Javie?

if (objectIsOfTypeFoo) { 
    if (objectOfTypeFooIsShared) { 
     // do something with Object of type Foo knowing that it's shared... 
    } else { 
     // do something with Object of type Foo knowing that it's not shared... 
    } 
} else if (objectIsOfTypeBar) { 
    ... 
} 

Stać:

if (objectIsOfTypeFoo) if (objectOfTypeFooIsShared) { 
    // do something with Object of type Foo knowing that it's shared... 
} else { 
    // do something with Object of type Foo knowing that it's not shared... 
} else if (objectIsOfTypeBar) { 
    ... 
} 

mogę zrozumieć, jak to ma sens, i kusi, by zgubić wcięcie, ale moim zmartwieniem jest to, że czytelność może ucierpieć. Ten ostatni wygląda czysto, ale czy zaoszczędzona przestrzeń jest warta potencjalnego zamieszania?

Zakładam, że różnica w wydajności między nimi jest banalna, jeśli w ogóle.

I jako pytanie uzupełniające: czy istnieje ograniczenie liczby "jeśli (stan) można zmieścić w pojedynczej linii, a raczej w jakim punkcie staje się zbyt wiele?

+4

Pierwszy przykład jest bardziej czytelny i rzadziej powoduje problemy z powodu pominiętych nawiasów klamrowych - IMHO – MadProgrammer

+2

Różnica w wydajności w czasie wykonywania jest zerowa, ponieważ kod-gen dla obu wersji jest identyczny. Różnica w wydajności podczas kompilacji to koszt leksykowania kilku dodatkowych nawiasów klamrowych. Tak więc zero. Och, i zignoruj ​​IDE: oferuje (moim zdaniem) okropną radę. – dlev

+0

Nigdy nie widziałem, żeby IntelliJ polecił coś takiego. Sprawdziłbym twoje ustawienia stylu. – duffymo

Odpowiedz

8

Głosuję za tym, jak już masz.

ja nawet nie korzystać z tego:

if(foo) 
    return bar; 

Lubię to zamiast:

if(foo){ 
    return bar; 
} 

"programy muszą być pisane dla ludzi do czytania, a jedynie incydentalnie dla maszyny do wykonywania"

+2

+1 - tak, rzeczywiście, ale dla stylu i idealnego cytatu. Osobiście polecam, abyś zaakceptował ten. – duffymo

+1

Nie zgadzam się, myślę, że jeśli if jest łatwe, jak gdyby (foo) rzucić wyjątek, nie jest złe. – nachokk

2

Wolałbym pierwszy. Myślę, że bit z wieloma ifs w jednym wierszu jest nieczytelny.

Przepraszam, ale zamierzam głosować, aby zamknąć. To będzie debata bez odpowiedzi.

+1

Fajne dzięki! Zamknij to! Wygląda na to, że mamy już konsensus :) – Liam

4

Zawsze używaj szelek. Pewnego dnia będziesz chciał umieścić drugie stwierdzenie w swoim bloku, jeśli lub w innym miejscu, a potem żałujesz, że nie miałeś. Czy jednak naprawdę sprawdzisz kontrole instanceof? Czy możesz przerobić program, aby zamiast tego zmienić go w zachowanie polimorficzne?

+1

Często, gdy ktoś pisze skomplikowany kod w ten sposób, dalsza myśl może go uprościć. Nawet jeśli nie jest łatwo mieć różne wersje 'Foo', być może' Foo' może pomieścić obiekt, który wie o strategii dzielenia się lub ma różne podklasy ze strategią udostępniania. Przypomnijmy list Pascala: "Przepraszam, że mój list był tak długi, że nie miałem czasu, aby go skrócić." –

+0

Tak, muszę generalizować klasę, ale na razie potrzebuję uzyskać to, co mam działa! – Liam

1

Zaleca się, aby zawsze używać nawiasów, ale tam jest sytuacja, kiedy nie ma sensu ciała szelki i to nie lepiej je za pomocą przyczyna jest bardziej czytelny

if(condition){ 

} else if (condition) { 
    ... 
}else if (condition3){ 

} 

jeśli zawsze używać szelek to będzie jak ten. Prawdopodobnie w którymś miejscu popełniam błąd.

if(condition){ 

} else{ 

     if (condition) { 
      ... 
     }else { 

      if (condition3){ 

      }//end if 
     }//end else 
}//end else 

więc myślę, że za pomocą zawsze zależy od czytelności, jak wyżej wspomniane programy muszą być pisane dla ludzi do czytania i tylko incydentalnie dla maszyny do wykonania.

Powiązane problemy