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

59

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.

Zannjaminderson
źródło
2
Ale masz nawias otwierający w niewłaściwej pozycji. To jest pewne.
Christian Mann,
W wielu językach blok jest instrukcją, stąd składniowo jest to zawsze instrukcja (wyrażenie)
Ingo
2
Ponieważ nie określiłeś języka ... Co powiesz na statement if condition;?
Dave Sherohman,
@Christian - dobry. To byłoby inne pytanie, niezależnie od tego, nie?
Zannjaminderson
@Ingo - dobry punkt.
Zannjaminderson

Odpowiedzi:

131

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ą.

dsimcha
źródło
35
Dobra uwaga na temat umieszczania wszystkiego w jednej linii.
Neil Aitken
7
@artjomka: Jeśli instrukcja jest długa i musi iść własną linią, używam nawiasów klamrowych dla zapewnienia czytelności. Chodzi o to, że chcesz mieć najkrótszą, najmniej składniowo hałaśliwą konstrukcję, która jest jednoznaczna dla człowieka, który czyta ją szybko, a nie analizuje.
dsimcha
15
Wolę ten z nawiasami klamrowymi z powodów już wspomnianych. Nie podoba mi się jeden-liner, ponieważ nie jest od razu oczywiste, co się stanie, gdy przekroczę linię w debuggerze. Muszę zrobić osobny krok, aby zobaczyć, jaki warunek ocenia.
Jim A
10
@TMN białe znaki są bezpłatne, monitory są duże, a mózg uczy się rozpoznawać kształt, który pomaga w analizie kodu.
Murph,
5
@Murph: białe znaki są bezpłatne? Musiałem to przegapić. Na moim ekranie zajmuje naprawdę dużo miejsca. O wiele więcej niż 50%. Co w mojej książce wydaje się dużym marnotrawstwem. Osobiście lubię maksymalizować zawartość kodu na centymetr kwadratowy.
Konrad Rudolph
44

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.

Neil Aitken
źródło
20
Czy ludzie naprawdę to widzieli? Nie sądzę, żebym kiedykolwiek widział to podczas 10 lat programowania. Może po prostu byłem zbyt osłonięty. :)
David
9
Chciałbym powiedzieć nie, ale niestety to widziałem.
Neil Aitken
13
Zawsze używasz nawiasów, aby nigdy nie zapomnieć o użyciu nawiasów - to takie proste.
Murph,
12
+1 do @ Morph. Z tego samego powodu używam kierunkowskazów, gdy nikogo nie ma w pobliżu - i na parkingach!
Dan Ray
7
Jest to dobra praktyka, aby zapobiec błędom podczas łączenia z gałęzi do pnia lub między gałęziami.
JBRWilkinson
27

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. 1

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.


1 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.

Konrad Rudolph
źródło
6
Pominięcie nawiasów klamrowych szkodzi czytelności i może łatwo powodować problemy podczas modyfikacji kodu.
Josh K
15
@Josh: pierwsze twierdzenie jest śmieszne, ponieważ języki takie jak Python pokazują (poprzyj to dowodami, jeśli uważasz inaczej). Drugi został odparty w mojej odpowiedzi. Czy masz dowody na poparcie tego? W przeciwnym razie twój komentarz wskazuje, że tak naprawdę nie przeczytałeś mojego tekstu. Zrób to, zanim go skrytykujesz.
Konrad Rudolph
8
+1 za twoje myśli, ale myślę, że twoja pozycja jest samowystarczalna. Mówisz „pokaż mi twarde dane, zebrane z eksperymentów naukowych, pokazując, że jest to rzeczywiście problem w praktyce”, a jednak opieraj się na niepotwierdzonych doświadczeniach (własnych), aby bronić swojej pozycji. Mówicie: „z mojego doświadczenia ... w mojej dekadzie doświadczenia ... uważam to za niewiarygodne ...” i tak dalej. Czy potrafisz pokazać twarde dane zebrane z eksperymentów naukowych, popierające twoje twierdzenie: „Pominięcie aparatu nie szkodzi”? Osobiste doświadczenie jest w porządku, jeśli popierasz opinię, ale nie proś o więcej „dowodów” niż jesteś w stanie udzielić.
bedwyr
3
@bedwyr: jest jednak różnica jakościowa. Po pierwsze, wyjaśniam, że dane mnie przekonają, i równie jasno stwierdzam, że moja jest jedynie hipotezą, nie popartą danymi. Po drugie, przedstawiłem (przynajmniej mi) prawdopodobny argument za moim przekonaniem, że twierdzenie jest fałszywe i dlaczego należy je potwierdzić. Co prowadzi mnie do trzeciego: ciężar spoczywa na opozycji, by udowodnić swoje roszczenie, a nie na mnie, by je obalić. Oprócz problemu wiarygodności pokazałem też jeden niepowiązany faktyczny argument wspierający mój styl kodowania.
Konrad Rudolph
4
@Konrad - python nie pokazuje inaczej, ponieważ wcięcie jest znaczące, a zatem nawiasy klamrowe są niejawne. Dobrzy bystrzy programiści, tacy, którzy tu są, prawdopodobnie nie popełniają błędu, jeśli w ogóle (przez wiele lat prawdopodobnie widziałem problem tylko przy kilku okazjach), ale jest wiele raczej mniej dobrych programiści, którzy robią głupie rzeczy, co jest jednym z powodów, dla których standardy kodowania są potrzebne. (A ponieważ terminy i stres mogą sprawić, że najlepsi z nas staną się mniej dobrzy.)
Murph,
19

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.

Steven Evers
źródło
11
absolutnie! mimo wszystko, jeśli kod był trudny do napisania, to też powinien być trudny do utrzymania! ;-)
Steven A. Lowe
3
@ Steven Jeśli zapomnisz aparat ortodontyczny, myślę, że są tu inne problemy.
TheLQ
więcej succint == mniej gadatliwy
UncleZeiv
5
@SnOrfus: nieco sarkastyczny, ponieważ dodatkowe 2 znaki są trywialne i zapobiegają bardzo częstemu błędowi konserwacji. Twój przebieg może się różnić ;-)
Steven A. Lowe
1
Dla mnie wcięcie wyjaśnia, co się dzieje. Pierwsza forma spala dodatkowe miejsce na ekranie, a zatem jest dla mnie negatywna.
Loren Pechtel
16

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 ;-)

kalosze
źródło
1
Dokładnie moje myśli. Jeśli pojedyncze zdanie wygląda dobrze w jednym wierszu po ifklauzuli, nie używam nawiasów klamrowych. W przypadku każdego innego ifwyrażenia (lub oświadczenia używającego wielu wierszy) zawsze używam nawiasów klamrowych. W szczególności, jeśli istnieje elseklauzula, każda sprawa ma zawsze nawiasy klamrowe.
eswald
9
Nigdy wcześniej nie widziałem, żeby ktoś mylił perla z pseudokodem. Losowe znaki tak, pseudokod - nie.
Joe D
3
Zastanawiam się, czy ktoś stworzył generator programu Perl po prostu podłączając / dev / random do interpretera Perla ...
Christian Mann,
Lubię podejście Ruby tutaj. Oferuje styl wiersza w stylu perla jedno- <statement> if <condition>lub wieloliniowy if <condition>/ <do something>/ end(ruby unika nawiasów klamrowych, więc tutaj nawias otwierający jest sugerowany przez, ifa nawias końcowy jest zastępowany literałem end). Nie oferuje nawet dziwnej instrukcji wielowierszowej, ale naprawdę tylko pojedynczej linii if.
Ben Lee,
Jednowierszowy nie działa z większością debuggerów (nie jest możliwe wywołanie przerwy, gdy treść klauzuli „if” ma zostać wykonana).
Peter Mortensen
11

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.

użytkownik36294
źródło
10

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.

Covar
źródło
3
Dokładnie! To nie nasza wina, że ​​nie zna składni.
kirk.burleson
3
Zły przykład. Dobry jest samochód ze źle umieszczonymi pedałami - gaz zamiast hamulca. To twój samochód, więc nie dbasz o nikogo innego. Problem polega na tym, że nie wiedzą o twoim unikalnym ustawieniu pedałów. Czy w tym przypadku jesteś dobrym inżynierem samochodowym?
yegor256
Byłaby to twoja wina, gdybyś dał im samochód wiedząc, że mogą być pijani. Podobnie powinniśmy starać się jak najmniej zakładać o przyszłych programistach, aby ułatwić konserwację.
Aram Kocharyan
8

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ą.

shimonyk
źródło
3
Kategorycznie nie kupuję oświadczenia o czytelności. Python jest jednym z najbardziej czytelnych języków i nie wymaga ograniczników. To twierdzenie jest po prostu nieprawdą. Nie kupuję też roszczenia dotyczącego konserwacji, ponieważ do tej pory było ono niesprawdzone i wciąż wielokrotnie modyfikowane. Ale w tym przypadku jestem bardzo zainteresowany dowodami empirycznymi. Jest to coś, co badanie może bardzo łatwo znaleźć i ustalić raz na zawsze.
Konrad Rudolph
Ponieważ Python używa wcięć zamiast ograniczników, domyślnie nie jest to prawidłowe porównanie.
Murph,
@Konrad - dowody empiryczne: Kiedy byłem nowym programistą, osobiście dodałem kod do nieobciążonego bloku, nie zdając sobie sprawy, że poprzedni programista nie zadał sobie trudu z nawiasami klamrowymi. Osobiście widziałem, jak inni robią to na własne oczy. To prawda, że ​​tylko raz widziałem, że ktoś potrzebuje pomocy w znalezieniu problemu po uruchomieniu kodu, ale miało to więcej wspólnego ze złymi umiejętnościami testowania.
shimonyk
@shimonyk: więc w zasadzie twoje obserwacje potwierdzają moje twierdzenie, że ten problem jest nieistotny? Nawiasem mówiąc, osobiste obserwacje są anegdotami, nie liczą się jako dowody empiryczne.
Konrad Rudolph
@Konrad bardzo dobrze, proszę również cytować swoje źródła. Zakładam, że masz recenzowane badanie z podwójnie ślepą próbą, do którego się odwołujesz? Jeśli nie, to jedynie lekceważenie własnych anegdot w celu udowodnienia, że ​​inni się mylą, podczas gdy domaganie się, by inne plakaty odwoływały się do „dowodów”, jest w najlepszym razie obłudne. Jak ktoś w dalszej części tego tematu napisał: „ciężar spoczywa na opozycji, by udowodnić swoje roszczenie, a nie na mnie, by je obalić”.
shimonyk
7

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 ;-)

Steven A. Lowe
źródło
4
Kiedyś to robiłem, ale przekonał mnie argument, że programiści muszą znać język i powinni myśleć.
kirk.burleson
2
Uważam, że to powszechna uprzejmość ... dla mojej przyszłej osobowości.
Steven A. Lowe
5

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.

jsternberg
źródło
Jeśli masz zamiar pisać makra, powinieneś je napisać, aby upewnić się, że można je wstawić do dowolnej części kodu, nie przerywając i tak.
Covar,
4

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();
    }
Dr Wily's Apprentice
źródło
3

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.

Vedran Krivokuća
źródło
1
Nigdy nie widziałem, żeby ktoś popełnił błąd, o którym mówisz.
kirk.burleson
1
Właśnie zrobiłem to wczoraj na czyimś innym kodzie. :-) Zastanawiam się po prostu, jak będzie wyglądał upstream, między innymi dodatkami do kodu, dodając nawiasy klamrowe na wszystkich swoich, jeśli tak, ponieważ wydaje się, że naprawdę jest z innej strony niż ja. :-) (uspokój się, żartuję, zredagowałem to, co musiałem ...)
Vedran Krivokuća,
2

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.

ChrisF
źródło
1

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!");
JohnFx
źródło
Zgadnij, że ktoś nie jest fanem zwięzłości.
JohnFx,
2
Zwięzłość ze względu na czytelność? Absolutnie nie. To kod, a nie zawody golfowe.
Josh K
3
Osobiście uważam, że czytelność jest doskonałym powodem zwięzłości. W każdym razie: Białe pola nie liczą się w moim kodzie golfowym.
JohnFx,
Jedynym
2
Więc nie nadużywaj tego. Nie mówię, że używaj go jako standardu kodowania. Często zdarza się, że masz bardzo krótki warunek, po którym następuje naprawdę krótkie pojedyncze zdanie i to działa dobrze. Na przykład if (assert) log.write („assert failed”);
JohnFx,
1

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; }
hotpaw2
źródło
Co ciekawe, tak naprawdę nie widzę takiego kodu, ale trochę mi się podoba.
Thomas Eding
0

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.

Uwaga do samodzielnego wymyślenia imienia
źródło
Równie łatwo można użyćreturn (obj != null) ? obj : "Error";
Josh K
@Josh, patrz edycja
Uwaga do siebie - pomyśl o nazwie
W takim przypadku użyłbym czegoś takiego Object returnObj = defaultObj; /* Three else-if's to change it to obj1/2/3 */ return returnObj;.
Josh K
@Josh, Przeczytaj przez stackoverflow.com/questions/36707/… . Pierwszy komentarz do pierwszej odpowiedzi: „Chociaż posiadanie wielu punktów wyjścia może wymknąć się spod kontroli, zdecydowanie uważam, że jest to lepsze niż umieszczenie całej funkcji w bloku IF ”.
Uwaga dla siebie - wymyśl nazwę
0

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.

nimcap
źródło