Czy używanie instrukcji if bez nawiasów klamrowych jest złą praktyką? [Zamknięte]

Widziałem taki kod:

if(statement)
    do this;
else
    do this;

Myślę jednak, że jest to bardziej czytelne:

if(statement){
    do this;
}else{
    do this;
}

Skoro obie metody działają, czy jest to po prostu kwestia preferencji, które należy zastosować, czy też jedna metoda byłaby zalecana zamiast drugiej?

Problem z pierwszą wersją polega na tym, że jeśli cofniesz się i dodasz drugą instrukcję do klauzul if lub else, nie pamiętając o dodaniu nawiasów klamrowych, kod zepsuje się w nieoczekiwany i zabawny sposób.

Jeśli chodzi o konserwację, zawsze mądrzej jest używać drugiej formy.

EDYCJA: Ned zwraca uwagę na to w komentarzach, ale myślę, że warto też tutaj linkować. To nie tylko hipotetyczne bzdury z wieży z kości słoniowej: https://www.imperialviolet.org/2014/02/22/applebug.html

Jednym z problemów związanych z pomijaniem bloków instrukcji jest niejednoznaczność else. Oznacza to, że języki inspirowane językiem C ignorują wcięcia, więc nie ma możliwości ich oddzielenia:

if(one)
    if(two)
        foo();
    else
        bar();

Od tego:

if(one)
    if(two)
        foo();
else
    bar();

Mój ogólny wzór jest taki, że jeśli zmieści się w jednej linii, zrobię:

if(true) do_something();

Jeśli istnieje klauzula else lub kod, na którym chcę wykonać, truema znaczną długość, użyj nawiasów klamrowych:

if(true) {
    do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}

if(false) {
    do_something();
} else {
    do_something_else();
}

Ostatecznie sprowadza się to do subiektywnej kwestii stylu i czytelności. Jednak ogólny świat programowania dzieli się na dwie części (w przypadku języków używających nawiasów klamrowych): albo używaj ich cały czas bez wyjątku, albo używaj ich cały czas z wyjątkiem. Należę do tej drugiej grupy.

Używam programu formatującego kod IDE, którego używam. To może się różnić, ale można to ustawić w Preferencjach / Opcjach.

Podoba mi się ten:

if (statement)
{
    // comment to denote in words the case
    do this;
    // keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
    do this;
}

„Zasada”, którą kieruję się jest następująca:

Jeśli instrukcja „if” testuje, aby coś zrobić (wywołanie funkcji IE, zmienne konfiguracyjne itp.), Użyj nawiasów.

if($test)
{
    doSomething();
}

Dzieje się tak, ponieważ czuję, że musisz wyjaśnić, jakie funkcje są wywoływane i dokąd zmierza przepływ programu, w jakich warunkach. Zrozumienie przez programistę dokładnie, jakie funkcje są wywoływane i jakie zmienne są ustawione w tym warunku, jest ważne, aby pomóc im dokładnie zrozumieć, co robi twój program.

Jeśli instrukcja „if” testuje, aby przestać coś robić (sterowanie przepływem IE w pętli lub funkcji), użyj jednej linii.

if($test) continue;
if($test) break;
if($test) return;

W tym przypadku dla programisty ważne jest szybkie odkrycie, jakie są wyjątkowe przypadki, w których nie chcesz, aby kod działał, a wszystko to jest objęte $ test, a nie blokiem wykonawczym.

Posiadanie nawiasów klamrowych od samego początku powinno pomóc w uniknięciu konieczności debugowania tego:

if (statement)
     do this;
else
     do this;
     do that;

Użyj nawiasów klamrowych dla wszystkich instrukcji if, nawet tych prostych. Lub przepisz prostą instrukcję if, aby użyć operatora trójargumentowego:

if (someFlag) {
 someVar= 'someVal1';
} else {
 someVar= 'someVal2';
}

Wygląda o wiele ładniej tak:

someVar= someFlag ? 'someVal1' : 'someVal2';

Ale używaj operatora trójskładnikowego tylko wtedy, gdy jesteś absolutnie pewien, że w blokach if / else nie ma nic więcej!

Wolę używać szelek. Dodanie nawiasów klamrowych ułatwia czytanie i modyfikowanie.

Oto kilka linków do korzystania z nawiasów klamrowych:

• Preferuj Multiline, jeśli

• Pomijanie szelek: nie tylko kwestia stylu

• Przepełnienie stosu

Z mojego doświadczenia jedyną (bardzo) małą zaletą pierwszej postaci jest czytelność kodu, druga forma dodaje „szumu”.

Ale dzięki nowoczesnym IDE i automatycznemu generowaniu kodu (lub autouzupełnianiu) zdecydowanie zalecam używanie drugiego formularza, nie będziesz spędzać dodatkowego czasu na pisaniu nawiasów klamrowych i unikniesz niektórych z najczęstszych błędów.

Jest wystarczająco dużo robaków pochłaniających energię, ludzie po prostu nie powinni otwierać drzwi, by tracić dużo czasu.

Jedną z najważniejszych zasad do zapamiętania podczas pisania kodu jest spójność. Każda linia kodu powinna być napisana w ten sam sposób, niezależnie od tego, kto ją napisał. Bycie rygorystycznym zapobiega "występowaniu" błędów;)

To samo dotyczy jasnego i jawnego nazywania zmiennych, metod, plików lub prawidłowego wcięcia ich ...

Kiedy moi uczniowie akceptują ten fakt, przestają walczyć z własnym kodem źródłowym i zaczynają postrzegać kodowanie jako naprawdę interesujące, stymulujące i twórcze działanie. Rzucają wyzwanie swoim umysłom, a nie nerwom!

To kwestia preferencji. Osobiście używam obu stylów, jeśli mam wystarczającą pewność, że nie będę już musiał dodawać zdań, używam pierwszego stylu, ale jeśli to możliwe, używam drugiego. Ponieważ nie można już dodawać stwierdzeń do pierwszego stylu, słyszałem, że niektórzy odradzają jego używanie. Jednak druga metoda wymaga dodatkowego wiersza kodu i jeśli Ty (lub Twój projekt) używasz tego rodzaju stylu kodowania, pierwsza metoda jest bardzo preferowana w przypadku prostych instrukcji if:

if(statement)
{
    do this;
}
else
{
    do this;
}

Myślę jednak, że najlepszym rozwiązaniem tego problemu jest Python. Dzięki strukturze blokowej opartej na białych znakach nie masz dwóch różnych metod tworzenia instrukcji if: masz tylko jedną:

if statement:
    do this
else:
    do this

Chociaż ma to „problem”, że nie możesz w ogóle używać nawiasów klamrowych, zyskujesz korzyść polegającą na tym, że nie ma już linii niż pierwszy styl i ma moc dodawania większej liczby instrukcji.

Zawsze starałem się, aby mój kod był standardowy i wyglądał jak najbliżej tego samego. Ułatwia to innym czytanie, gdy są odpowiedzialne za aktualizację. Jeśli zrobisz pierwszy przykład i dodasz do niego linię w środku, zakończy się niepowodzeniem.

Nie zadziała:

if (instrukcja) zrób to; i to; inaczej zrób to;

Osobiście używam pierwszego stylu tylko rzucam wyjątek lub przedwcześnie wracam z metody. Jak sprawdzanie argumentów na początku funkcji, ponieważ w takich przypadkach rzadko mam więcej niż jedną rzecz do zrobienia i nigdy nie ma innej.

Przykład:

if (argument == null)
    throw new ArgumentNullException("argument");

if (argument < 0)
    return false;

W przeciwnym razie używam drugiego stylu.

Moje osobiste preferencje to mieszanka białych znaków i nawiasów w następujący sposób:

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

Myślę, że wygląda to na czysty i sprawia, że ​​mój kod jest bardzo łatwy do odczytania, a co najważniejsze - debugowania.

Zgadzam się z większością odpowiedzi w tym, że lepiej jest być wyraźnym w swoim kodzie i używać nawiasów klamrowych. Osobiście przyjąłbym zestaw standardów kodowania i upewniłbym się, że wszyscy w zespole je znają i przestrzegają. Tam, gdzie pracuję, używamy standardów kodowania opublikowanych przez IDesign.net dla projektów .NET.

Wolę zakładać klamrę kręconą Ale czasami pomaga operator trójskładnikowy.

Zamiast :

int x = 0;
if (condition) {
    x = 30;
} else {
    x = 10;
}

Należy po prostu zrobić: int x = condition ? 30 : 20;

Wyobraź sobie również przypadek:

if (condition)
    x = 30;
else if (condition1)
    x = 10;
else if (condition2)
    x = 20;

Byłoby znacznie lepiej, gdybyś założył klamrę kręconą.