Pojedyncza instrukcja, jeśli nawiasy blokowe czy nie? [Zamknięte]

Który jest lepszy / bardziej ogólnie akceptowany?

To:

if(condition)
{
  statement;
}

Lub:

if(condition)
  statement;

Wolę ten pierwszy, ponieważ uważam, że łatwiej jest stwierdzić, co faktycznie należy do bloku if, ratuje innych przed późniejszym dodawaniem nawiasów klamrowych (lub tworzeniem błędu przez zapominanie o) i sprawia, że ​​wszystkie twoje instrukcje if jednolite zamiast niektórych z aparatami ortodontycznymi, a niektóre bez. Drugi jest jednak nadal poprawny pod względem składniowym i zdecydowanie bardziej zwarty. Ciekawi mnie jednak, który jest bardziej preferowany przez innych.

Pierwszy jest lepszy, ponieważ drugi jest podatny na błędy. Załóżmy na przykład, że tymczasowo komentujesz kod w celu debugowania:

if(condition) 
//      statement;
otherStatement;

Lub w pośpiechu dodając kod:

if(condition) 
    statement;
    otherStatement;

To jest oczywiście złe. Z drugiej strony, ten pierwszy czasami wydaje się zbyt rozwlekły. Dlatego wolę po prostu umieścić wszystko w jednym wierszu, jeśli jest wystarczająco krótkie i proste:

if(condition) statement;

Ogranicza to hałas syntaktyczny, jednocześnie sprawiając, że konstrukcja wygląda tak, jak robi to, co faktycznie robi, dzięki czemu jest mniej podatna na błędy. Pod warunkiem, że ta składnia jest używana tylko dla bardzo prostych, krótkich warunków i instrukcji, uważam ją za doskonale czytelną.

Zawsze używam nawiasów, aby być bezpiecznym.

Pisanie go jest w porządku, ale wiesz, że ktoś przyjdzie w przyszłości i wstawi kolejne zdanie bez umieszczania nawiasów.

W miarę możliwości wolę wersję bez nawiasów klamrowych .

Poniższe wyjaśnienie jest długie. Proszę o wyrozumiałość. Podam przekonujący powód, dla którego wolę ten styl. Wyjaśnię również, dlaczego uważam, że zwykły kontrargument nie ma zastosowania.

(Prawie) puste linie to marnotrawstwo

Powodem tego jest to, że nawias zamykający wymaga dodatkowej linii kodu - podobnie jak nawias otwierający, w zależności od stylu. ¹

Czy to wielka sprawa? Pozornie nie. W końcu większość ludzi umieszcza puste wiersze w kodzie, aby oddzielić logicznie nieco niezależne bloki, co znacznie poprawia czytelność.

Nie cierpię jednak marnowania pionowej przestrzeni. Nowoczesne monitory mają w rzeczywistości dużo przestrzeni poziomej. Ale przestrzeń pionowa jest nadal bardzo, bardzo ograniczona (chyba że używasz monitora ustawionego pionowo, co nie jest rzadkie). Problemem jest ta ograniczona przestrzeń pionowa : powszechnie uznaje się, że poszczególne metody powinny być jak najkrótsze, a odpowiadające nawiasy klamrowe (lub inne ograniczniki bloków) powinny mieć nie więcej niż różnicę wysokości ekranu, aby można było zobaczyć cały blok bez przewijanie.

Jest to podstawowy problem: gdy nie widzisz już całego bloku na ekranie, jego zrozumienie staje się skomplikowane.

W konsekwencji nie cierpię zbędnych pustych linii. Tam, gdzie pojedyncze puste linie mają kluczowe znaczenie dla rozgraniczenia niezależnych bloków (wystarczy spojrzeć na wygląd tego tekstu), kolejne puste linie są bardzo złym stylem w mojej książce (i z mojego doświadczenia są zazwyczaj znakiem początkujących programistów).

Podobnie powinny być linie, które po prostu trzymają klamrę i które mogłyby być oszczędzone. Blok pojedynczej instrukcji, który jest ograniczony nawiasami klamrowymi, marnuje jeden do dwóch wierszy. Widoczne jest to tylko przy 50 liniach na wysokość ekranu.

Pominięcie nawiasów klamrowych może nie zaszkodzić

Jest tylko jeden argument przeciwko pomijaniu nawiasów klamrowych: ktoś później doda kolejną instrukcję do danego bloku i zapomni o dodaniu nawiasów klamrowych, tym samym nieumyślnie zmieniając semantykę kodu.

To naprawdę byłaby wielka sprawa.

Ale z mojego doświadczenia tak nie jest. Jestem niedbałym programistą; a jednak, w mojej dekadzie doświadczenia w programowaniu, mogę szczerze powiedzieć, że nie zapomniałem kiedyś dodać nawiasów klamrowych, dodając dodatkową instrukcję do bloku singletonu.

Uważam nawet za niewiarygodne, że powinien to być powszechny błąd: bloki są podstawową częścią programowania. Rozdzielczość i określanie zakresu bloków jest automatycznym, zakorzenionym procesem umysłowym dla programistów. Mózg po prostu to robi (inaczej rozumowanie na temat programowania byłoby znacznie trudniejsze). Nie jest wymagany żaden dodatkowy wysiłek umysłowy, aby pamiętać o założeniu nawiasów klamrowych: programista pamięta przecież, że w końcu prawidłowo wcina nowo dodane polecenie; więc programista już mentalnie przetworzył, że w grę wchodzi blok.

Teraz jestem nie mówiąc, że pomijając szelki nie powodować błędy. Mówię tylko, że nie mamy dowodów w ten czy inny sposób. Po prostu nie wiemy, czy to powoduje szkody.

Tak więc, dopóki ktoś nie pokaże mi twardych danych zebranych z eksperymentów naukowych, wykazujących, że jest to rzeczywiście problem w praktyce, teoria ta pozostaje „ tylko taką historią ”: bardzo przekonującą hipotezą, która nigdy nie została przetestowana, i że musi nie być używane jako argument.

¹ Ten problem czasami rozwiązuje się, umieszczając wszystko - w tym szelki - w tej samej linii:

if (condition)
{ do_something(); }

Uważam jednak, że można śmiało powiedzieć, że większość ludzi gardzi tym. Co więcej, miałby takie same problemy jak wariant bez nawiasów klamrowych, więc jest to najgorszy z obu światów.

Idę z drugim. Jest bardziej zwięzły i mniej gadatliwy.

Staram się nie pisać do najniższego wspólnego mianownika, więc spodziewam się, że inni programiści wiedzą, jak napisać jedną z najbardziej powszechnych struktur przepływu sterowania w programowaniu.

Użyłbym następujących (tutaj konsensus):

if (condition) {
    any_number_of_statements;
}

Również możliwe:

if(condition) single_compact_statement;

Nie tak dobrze, szczególnie w językach podobnych do C / C ++:

if(condition) 
    single_compact_statement;

(W Pythonie nie ma wyboru ;-)

W Perlu użyłbyś:

$C = $A**3 if $A != $B;

lub

$C = $A**3 unless $A == $B;

(To nie jest pseudokod ;-)

Używam metody nawiasów klamrowych - z powyższych powodów plus jeszcze jedna.

Kod się łączy. Wiadomo, że dzieje się to przy projektach, nad którymi pracowałem nad tym pojedynczym stwierdzeniem, jeśli zostały zerwane przez automatyczne połączenia. Straszne jest to, że wcięcie wygląda dobrze, mimo że kod jest nieprawidłowy, więc tego typu błąd jest trudny do wykrycia.

Więc idę z nawiasami klamrowymi - na własnych liniach. W ten sposób łatwiej jest dostrzec poziomy. Tak, marnuje nieruchomości z pionowym ekranem, co jest prawdziwym minusem. Podsumowując, myślę, że warto.

Bez nawiasów klamrowych. Jeśli jakiś inny programista doda do mojego kodu drugie zdanie, to nie będzie to moja wina, że ​​pozwolę, aby ktoś prowadził mój samochód i przejechał klif.

Dyskutowaliśmy tu więcej niż jeden raz i ogólną zgodą jest zawsze stosowanie nawiasów klamrowych. Głównymi powodami są czytelność / łatwość konserwacji.

Jeśli chcesz dodać kod do ifbloku, nie musisz pamiętać / wyszukiwać nawiasów klamrowych. Kiedy przyszli programiści czytają kod, nawiasy klamrowe są zawsze jednoznaczne.

Na plus, ReSharper automatycznie doda nawiasy klamrowe dla leniwych programistów w Visual Studio i zakładam, że istnieją dodatki dla innych IDE, które to zrobią.

Używam pierwszej składni, prawie bez wyjątku. Ponieważ nie można tego źle interpretować .

„Nie każ mi myśleć” nie dotyczy tylko interfejsów użytkownika, wszyscy ;-)

Ja osobiście wolę drugi. Pierwszy wygląda brzydko, niezręcznie i marnuje poziomą przestrzeń. Głównymi problemami z drugim problemem są makra i ludzie modyfikujący kod w późniejszym czasie, popełniający błąd.

Mówię do tego „nie używaj makr”. Mówię też: „poprawnie wciskaj swój cholerny kod”. Biorąc pod uwagę, jak każdy edytor tekstu / IDE używany do programowania wykonuje wcięcia automatycznie, nie powinno to być takie trudne. Podczas pisania kodu w Emacsie użyłbym automatycznego wcięcia, aby stwierdzić, czy napisałem coś źle w poprzednim wierszu. Za każdym razem, gdy Emacs zaczyna niszczyć wcięcia, zwykle wiem, że zrobiłem coś złego.

W praktyce kończę zgodnie z konwencją kodowania, która została mi postawiona. Ale te mnie denerwują (i sprawiają, że jestem znacznie szczęśliwszy, gdy koduję w Pythonie i cała katastrofa zniknęła):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Następnie

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Chociaż szczerze mówiąc, dwa stwierdzenia w oświadczeniu if denerwują mnie znacznie bardziej niż jedno oświadczenie. Głównie dlatego, że wtedy wymagane są nawiasy i nadal wygląda to śmiesznie, mając tylko dwie instrukcje w instrukcji if.

Używam wersji dwuwierszowej bez nawiasów klamrowych (2. forma), ale nie w celu oszczędzania miejsca.

Używam tego formularza, ponieważ uważam go za bardziej czytelny, bardziej atrakcyjny wizualnie i łatwiejszy do pisania. Używam tego formularza tylko wtedy, gdy te warunki są spełnione; tzn. ifwarunek musi dobrze pasować do jednego wiersza, a odpowiednie oświadczenie musi dobrze pasować do następnego wiersza. Jeśli tak nie jest, użyję nawiasów klamrowych, aby poprawić czytelność.

Jeśli używam tego formularza, upewniam się, że przed ifinstrukcją i po niej (lub nad komentarzem, jeśli jest obecny) jest pusta linia (lub linia zawierająca tylko nawias klamrowy ). Chociaż nie jest to reguła, którą świadomie przestrzegam, zauważam ją teraz po przeczytaniu tego pytania.

Oszczędzanie miejsca na ekranie nie jest dla mnie priorytetem. Gdybym potrzebował więcej miejsca, użyłbym większego monitora. Mój ekran jest już na tyle duży, że mogę odczytać wszystko, na co mogę zwrócić uwagę. Jest mało prawdopodobne, żebym musiał skupić się na tak wielu liniach kodu, że zajmują one cały ekran. Jeśli dzieje się tak wiele zagnieżdżeń z fragmentem kodu, że nie mogę go zrozumieć bez obejrzenia większej ilości kodu naraz, musiałbym rozważyć, czy logikę można lepiej przedstawić przez refaktoryzację.

Poniżej znajduje się kilka przykładów, które pokazują, jak korzystam z tej formy ifoświadczenia.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Szelki Zawsze. Jestem ich fanem, ponieważ nadaje kodowi pewną spójność. A także, jak napisał @dsimcha - mniejsza szansa na błędy przy dodawaniu dodatkowych wierszy kodu.

„Brzydota” nawiasów klamrowych wokół pojedynczej linii kodu jest mniej szkodliwa niż dodatkowa praca, która jest prawdopodobna w przypadkach debugowania i / lub dodawania kodu.

Osobiście idę z nawiasami.

Dlaczego?

Cóż, jeśli ktoś przyjdzie i musi dodać kod do instrukcji if, to w 100% jasne, gdzie jest zakres.

Utrzymuje ifspójność formatu instrukcji bez względu na liczbę instrukcji w bloku.

Jeśli jednak styl projektu ma się obejść, trzymaj się tego.

Prawie zawsze używam wsporników, aby być po bezpiecznej stronie. Czasami jednak, jeśli zawartość bloku jest naprawdę krótka, zostawię je i uczynię z tego jedno-liniowego:

if (x==5) Console.WriteLine("It's a five!");

Wolę nawiasy klamrowe ze względu na spójność, ale nie marnowanie zbyt dużej ilości wolnego miejsca (więc bardziej czytelny format jest w moim ograniczonym polu widzenia). Więc piszę to dla krótkich wierszy:

If (cond) { statement; }

Zwykle używam aparatu ortodontycznego, ale w niektórych przypadkach nie.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Dla mnie głupotą byłoby ich tam dodać. Jeśli ktoś doda oświadczenie po return, mamy większe problemy niż problemy dotyczące zakresu.

Jeśli IDE ma dostępne formatowanie kodu, nie używam nawiasów klamrowych.

Z drugiej strony, gdy kod może być edytowany w innych edytorach, które nie obsługują automatycznego formatowania, niebezpiecznie jest nie umieszczać nawiasów klamrowych, jak wspomniano w innych postach. Ale mimo to wolę nie używać aparatów ortodontycznych i nie stanowiło to dla mnie problemu.