Dlaczego pomijanie nawiasów klamrowych uważa się za złą praktykę? [Zamknięte]

Dlaczego wszyscy mówią mi, że pisanie takiego kodu jest złą praktyką?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

Moim największym argumentem za pominięciem nawiasów klamrowych jest to, że czasami może zawierać dwa razy więcej wierszy. Na przykład, oto kod do malowania efektu blasku dla etykiety w C #.

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

Możesz także uzyskać dodatkową korzyść z łączenia w łańcuch usingsbez konieczności wciskania milion razy.

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

Najczęstszy argument za nawiasami klamrowymi dotyczy programowania konserwacyjnego i problemów, które wynikną z wstawienia kodu między oryginalną instrukcję if a jej zamierzonym wynikiem:

if (foo)
    Bar();
    Biz();

Pytania:

1. Czy źle jest chcieć używać bardziej zwartej składni, jaką oferuje język? Ludzie, którzy projektują te języki, są sprytni, nie wyobrażam sobie, żeby umieścili funkcję, która zawsze jest niewłaściwa.
2. Powinniśmy czy nie powinniśmy napisać kod tak, aby najniższy wspólny mianownik mógł go zrozumieć i nie miał z nim problemów?
3. Czy jest inny argument, którego mi brakuje?

Właściwie jedyny raz, kiedy naprawdę mnie ugryzł, to debugowanie i skomentowanie bar ():

if(foo)
  // bar();
doSomethingElse();

Poza tym zwykle używam:

if(foo) bar();

Który załatwia powyższy przypadek.

EDYCJA Dziękuję za wyjaśnienie pytania, zgadzam się, nie powinniśmy pisać kodu do najniższego wspólnego mianownika.

Szybkość czytania ...

Oprócz tego, co już zostało wspomniane. W tym momencie zostałem już uwarunkowany analizowaniem instrukcji if z nawiasami klamrowymi i spacjami. Przeczytałem więc:

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Nieco szybciej niż czytałem:

if (condition) DoSomething();

DoSomethingElse();

Czytam to trochę wolniej, jeśli wygląda to tak:

if (condition) DoSomething();
DoSomethingElse();

Czytam to znacznie wolniej niż poprzedni:

if (condition) 
    DoSomething();
DoSomethingElse();

ponieważ nie mogę się powstrzymać od przeczytania go ponownie na wszelki wypadek i zastanawiam się, czy autor miał zamiar:

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

Omówiono już ogólnie, ale jeśli chodzi o przeczytanie poniżej, będę się temu przyglądać przez dłuższy czas, aby upewnić się, co zamierzał autor. Może nawet wytropię oryginalnego autora, aby to potwierdzić.

if (condition) 
    DoSomething();
    DoSomethingElse();

Jeśli to coś małego, napisz to tak:

if(foo()) bar();

Jeśli jest wystarczająco długi, aby podzielić na dwie linie, użyj nawiasów klamrowych.

Uważałem też, że lepiej jest używać szelek tylko wtedy, gdy są naprawdę potrzebne. Ale już nie, główny powód, dla którego masz dużo kodu, czyni go bardziej czytelnym i możesz szybciej przeanalizować kod, jeśli masz spójny styl nawiasów klamrowych.

Innym dobrym powodem, dla którego zawsze należy używać nawiasów klamrowych, poza tym, że ktoś dodaje drugą instrukcję do if, może się zdarzyć coś takiego:

if(a)
   if(b)
     c();
else
   d();

Czy zauważyłeś, że klauzula else jest faktycznie klauzulą ​​„if (b)”? Prawdopodobnie tak, ale czy zaufałbyś komuś, kto znał ten chwyt?

Tak więc, jeśli tylko dla spójności i ponieważ nigdy nie wiesz, jakie nieoczekiwane rzeczy mogą się wydarzyć, gdy ktoś inny (to zawsze inni są głupi) zmieni kod, zawsze umieszczam nawiasy klamrowe, ponieważ sprawia, że ​​kod źródłowy jest bardziej czytelny, szybszy do przeanalizowania przez Twój mózg. Tylko w przypadku najprostszych instrukcji if, takich jak if, w których następuje delegacja lub jest ona podobna do przełącznika, gdzie wiesz, że klauzula nigdy nie zostanie rozszerzona, pominę nawiasy klamrowe.

Nie zawsze jest to uważane za złą praktykę. W Mono projektowe Wytyczne kodowania nie sugeruje użycie nawiasów klamrowych, jeśli nie jest to konieczne. To samo dotyczy standardów kodowania GNU . Myślę, że to kwestia osobistego gustu, jak zawsze w przypadku standardów kodowania.

Linie są tanie. Moc procesora jest tania. Czas programisty jest bardzo drogi.

Z reguły, jeśli nie opracowuję jakiejś aplikacji, która ma absolutnie kluczowe znaczenie dla zasobów / szybkości, zawsze popełniłbym błąd po stronie pisania kodu, czyli

(a) Każdy inny programista może łatwo śledzić to, co robię

(b) Skomentuj określone części kodu, które mogą tego wymagać

(c) Łatwe do debugowania, jeśli coś pójdzie nie tak

(d) Łatwe do modyfikacji, jeśli zajdzie taka potrzeba w przyszłości (np. dodanie / usunięcie kodu)

Szybkość lub akademicka elegancja kodu jest drugorzędna w stosunku do tych czynników z biznesowego punktu widzenia. Nie oznacza to, że postanowiłem napisać niezgrabny lub brzydki kod, ale to jest MOJA kolejność priorytetów.

Pomijanie nawiasów klamrowych w większości przypadków sprawia, że ​​(b), (c) i (d) są trudniejsze (uwaga nie jest jednak niemożliwa). Powiedziałbym, że używanie nawiasów klamrowych lub nie ma wpływu na (a).

Wolę przejrzystość, jaką zapewnia klamra kręcona. Wiesz dokładnie, co to znaczy i nie musisz zgadywać, czy ktoś po prostu go oszukał i zostawił (i wprowadził błąd). Pomijam je tylko wtedy, gdy umieszczam if i akcję w tej samej linii. Ja też nie robię tego zbyt często. Właściwie wolę białe spacje wprowadzone przez umieszczenie nawiasu klamrowego we własnej linii, chociaż od lat programowania w stylu K&R C, kończenie wiersza nawiasem klamrowym jest praktyką, nad którą muszę pracować, aby przezwyciężyć, jeśli IDE nie wymusza tego dla mnie.

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}

Myślę, że to kwestia wytycznych dotyczących projektu, nad którym pracujesz, i osobistego gustu.

Zwykle pomijam je, gdy nie są potrzebne, z wyjątkiem niektórych przypadków, takich jak:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

wolę

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}

Jednym z przypadków, w których może to cię ugryźć, jest dawne makra C / C ++. Wiem, że jest to kwestia C #, ale często standardy kodowania są przenoszone bez powodu, dla którego standard został stworzony w pierwszej kolejności.

Jeśli nie jesteś bardzo ostrożny podczas tworzenia makr, możesz spowodować problemy z instrukcjami if, które nie używają {}.

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

Nie zrozum mnie źle, nie mówię, że zawsze powinieneś robić {} tylko po to, aby uniknąć tego problemu w C / C ++, ale z tego powodu miałem do czynienia z kilkoma bardzo dziwnymi błędami.

Zwykłem myśleć w ten sam sposób.

Aż pewnego dnia (dlaczego zawsze jest ten „jeden dzień”, który na zawsze zmienia twoje życie?) Spędzamy od 24 do 36 godzin bez debugowania kodu produkcyjnego tylko po to, by dowiedzieć się, że ktoś nie założył nawiasów klamrowych połączonych ze zmianą wyszukiwania / zamiany .

To było coś takiego.

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

To, co przyszło później, było

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

Okazuje się, że system generował 500 MB logów dziennie i zostaliśmy poproszeni o jego zatrzymanie. Flaga debugowania nie była wystarczająca, więc wyszukiwanie i zamiana println były w porządku.

Mimo to, gdy aplikacja została uruchomiona, flaga debugowania była wyłączona, a ważne polecenie „saveDayData” nigdy nie zostało wywołane.

EDYTOWAĆ

Teraz jedynym miejscem, w którym nie używam nawiasów, jest konstrukcja if / try.

if( object != null ) try { 
     object.close();
} catch( .....

Po obejrzeniu, jak robi to supergwiazda.

Mówiąc szczerze, widzę to jako:

Dobrzy programiści programują defensywnie, źli programiści nie.

Ponieważ jest kilka przykładów powyżej i moje własne podobne doświadczenia z błędami związanymi z zapominaniem aparatu ortodontycznego, nauczyłem się trudnej drogi, aby ZAWSZE ZAKŁADAĆ SZELKI.

Cokolwiek innego to wybór osobistego stylu zamiast bezpieczeństwa, a to wyraźnie złe programowanie.

Joel nawet wspomina o tym w Making Wrong Code Look Wrong

Gdy zostaniesz ugryziony przez błąd z powodu brakujących nawiasów, dowiesz się, że brakujące nawiasy wyglądają nieprawidłowo, ponieważ wiesz, że jest to potencjalne miejsce na wystąpienie kolejnego błędu.

Bardzo się cieszę, że:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Osobiście nie rozumiem dlaczego

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

jest bardziej czytelny.

Tak, wiersze są darmowe, ale po co przewijać strony i strony kodu, skoro rozmiar może być o połowę mniejszy?

Jeśli istnieje różnica w czytelności lub łatwości konserwacji, to oczywiście, wstaw nawiasy klamrowe ... ale w tym przypadku nie widzę powodu, aby to robić.

Poza tym zawsze będę umieszczać nawiasy klamrowe dla zagnieżdżonych ifów, w których zagnieżdżono inne

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

vs

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

jest strasznie zagmatwana, więc zawsze piszę to jako:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

O ile to możliwe, używam operatorów trójskładnikowych, ale nigdy ich nie zagnieżdżam .

Zgadzam się, że „jeśli jesteś na tyle sprytny, by skłonić kogoś, by zapłacił ci za pisanie kodu, powinieneś być na tyle sprytny, aby nie polegać wyłącznie na wcięciach, aby zobaczyć przepływ kodu”.

Jednak ... błędy mogą zostać popełnione, a ten jest trudny do debugowania ... zwłaszcza jeśli przychodzisz do kodu kogoś innego.

Moja filozofia jest taka, że ​​jeśli dzięki temu kod będzie bardziej czytelny, dlaczego nie?

Oczywiście musisz gdzieś wyznaczyć granicę, na przykład znaleźć to szczęśliwe medium między zwięzłymi i nadmiernie opisowymi nazwami zmiennych. Ale nawiasy naprawdę pozwalają uniknąć błędów i poprawiają czytelność kodu.

Można argumentować, że ludzie wystarczająco sprytni, by być programistami, będą na tyle sprytni, aby uniknąć błędów, które wynikają z instrukcji bez nawiasów klamrowych. Ale czy możesz szczerze powiedzieć, że nigdy nie wpadłeś na coś tak prostego jak błąd ortograficzny? Taka Minutia może być przytłaczająca, patrząc na duże projekty.

Zawsze są wyjątki, ale sprzeciwiłbym się pomijaniu nawiasów klamrowych tylko wtedy, gdy występuje w jednej z form:

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

W przeciwnym razie nie mam z tym problemu.

Czasami używam bardzo dolnego kodu (wiele instrukcji using), ale poza tym zawsze umieszczam nawiasy klamrowe. Uważam, że dzięki temu kod jest bardziej przejrzysty. Jest oczywiste z czegoś więcej niż tylko wcięcia, że ​​instrukcja jest częścią bloku (a zatem prawdopodobnie częścią if itp.).

Widziałem

if (...)
    foo();
    bar();

błąd mnie ugryzł (a raczej „ja i koledzy” - właściwie nie przedstawiłem błędu) raz . Stało się tak pomimo faktu, że nasze ówczesne standardy kodowania zalecały używanie wszędzie nawiasów klamrowych. Zajęło mi to zaskakująco dużo czasu - bo widzisz to, co chcesz. (To było około 10 lat temu. Może teraz znajdę to szybciej).

Oczywiście użycie nawiasu klamrowego na końcu linii zmniejsza liczbę dodatkowych linii, ale osobiście i tak nie lubię tego stylu. (Używam go w pracy i uważam, że jest mniej nieprzyjemny, niż się spodziewałem, ale nadal jest trochę nieprzyjemny.)

Jestem pod wrażeniem i pokorą, że moi rówieśnicy w tej dziedzinie programowania komputerowego (was, wielu) nie są zrażeni perspektywą potencjalnych błędów, gdy pominiesz nawiasy klamrowe w blokach jednowierszowych.

To chyba znaczy, że nie jestem mądry. Wiele razy popełniałem przy tym błędy. Debugowałem błędy innych w tym zakresie. Widziałem, jak oprogramowanie jest dostarczane z błędami z tego powodu (RDP do maszyny z VS2002 i czcionka w oknie zegarka nie będzie działać).

Jeśli spojrzę na wszystkie błędy, które popełniłem, których można było uniknąć, zmieniając styl kodowania, lista jest bardzo długa. Gdybym nie zmienił swojego podejścia w każdym z tych przypadków, prawdopodobnie nigdy nie zrobiłbym tego jako programista. Znowu, chyba nie jestem mądry. Aby to zrekompensować, przez długi czas byłem zagorzałym użytkownikiem nawiasów klamrowych na blokach jednowierszowych.

To powiedziawszy, na świecie zmieniły się pewne rzeczy, które sprawiają, że zasada „będziesz używać szelek na blokach jednowierszowych” jest dziś mniej aktualna niż wtedy, gdy Mojżesz sprowadził ją do nas:

• W niektórych popularnych językach problem znika, zmuszając komputer do odczytywania wcięć, tak jak robi to programista (np. Python).

• Mój edytor automatycznie formatuje dla mnie, więc szanse na wprowadzenie w błąd przez wcięcia są znacznie mniejsze.

• TDD oznacza, że ​​jeśli wprowadzę błąd, ponieważ jestem zdezorientowany przez blok jednowierszowy, znacznie bardziej prawdopodobne jest, że szybko go odkryję.

• Refaktoryzacja i ekspresyjność języka powodują, że moje bloki są znacznie krótsze, a bloki jednowierszowe zdarzają się znacznie częściej niż zwykle. Hipotetycznie, przy bezwzględnym zastosowaniu ExtractMethod, mógłbym mieć tylko jednowierszowe bloki w całym moim programie. (Zastanawiam się, jak to by wyglądało?)

W rzeczywistości bezlitosna refaktoryzacja i pomijanie nawiasów klamrowych w blokach jednowierszowych może przynieść wyraźną korzyść: kiedy widzisz nawiasy klamrowe, w Twojej głowie może zadzwonić mały alarm z napisem „tu złożoność! Uwaga!”. Wyobraź sobie, że to norma:

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

Otwieram się na pomysł zmiany mojej konwencji kodowania na coś w rodzaju „bloki jednowierszowe mogą nigdy nie mieć nawiasów klamrowych” lub „jeśli można umieścić blok w tym samym wierszu co warunek, a wszystko mieści się w 80 znakach, pomiń nawiasy ". Zobaczymy.

Spośród trzech konwencji:

if(addCurleyBraces()) bugFreeSofware.hooray();

i:

if(addCurleyBraces())
    bugFreeSofware.hooray();

i (które reprezentują dowolny styl wcięcia przy użyciu otwierającego i zamykającego nawiasu klamrowego):

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

Wolę ten ostatni jako:

• Łatwiej jest mi się czytać, jeśli wszystkie instrukcje „jeśli” są zapisane w jednolity sposób.
• Może to sprawić, że oprogramowanie będzie trochę bardziej niezawodne i wolne od błędów. Jednak wszystkie nowoczesne IDE i zaawansowane edytory tekstu mają ładne funkcje automatycznego wcięcia, których myślę, że każdy powinien używać, o ile nie psuje formatowania komentarzy ani nie jest sprzeczny ze standardami zespołowymi (w wielu przypadkach możliwe jest stworzenie niestandardowego schematu formatowania i podziel się nim z zespołem). Chodzi mi o to, że jeśli wcięcie jest wykonane poprawnie, ryzyko wprowadzenia błędu jest nieco zmniejszone.
• Wolę, aby wyrażenie boolowskie i instrukcje do wykonania znajdowały się w różnych wierszach. Lubię mieć możliwość zaznaczenia wiersza do celów debugowania. Nawet jeśli używam IDE, w którym mogę zaznaczyć oświadczenie i przejść do niego, jest to operacja interaktywna i mogę zapomnieć, gdzie zacząłem debugować, lub przynajmniej zajmie mi to trochę więcej czasu, aby przejść przez kod kilka razy (ponieważ za każdym razem muszę ręcznie zaznaczyć pozycję podczas debugowania).

Twoje główne argumenty przeciwko używaniu nawiasów klamrowych to fakt, że używają one dodatkowych wierszy i wymagają dodatkowego wcięcia.

Linie są (prawie) wolne, więc minimalizacja liczby wierszy w kodzie nie powinna być celem.

Wcięcie jest niezależne od użycia nawiasów klamrowych. W twoim kaskadowym przykładzie „używania” nadal uważam, że powinieneś wcinać je, nawet jeśli pominiesz nawiasy klamrowe.

Mocno wierzę w pisanie uporządkowanego i zwięzłego kodu, ale zawsze używałbym nawiasów klamrowych. Uważam, że są one wygodnym sposobem szybkiego sprawdzenia zakresu, w którym istnieje określony wiersz kodu. Nie ma dwuznaczności, jest po prostu wyraźnie przedstawione przed tobą.

Niektórzy mogą powiedzieć, że jest to przypadek preferencji, ale uważam, że logiczny przepływ programu jest znacznie łatwiejszy do prześledzenia, jeśli jest wewnętrznie spójny, i nie uważam, że spójne jest napisanie takiej instrukcji IF;

if(x < y)
    x = y;
else
    y = x;

I jeszcze jeden taki;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

Wolę tylko wybrać jeden ogólny styl i się go trzymać :)

Jednym z głównych problemów jest, gdy masz regiony jednej wkładki i non-ONE wkładki wraz z oddzieleniem od statment kontrolnej ( for, if, co masz) i koniec statment.

Na przykład:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}

Kiedyś byłem wielkim zwolennikiem „nawiasów klamrowych to MUSI!”, Ale od czasu przyjęcia testów jednostkowych stwierdziłem, że moje testy jednostkowe chronią instrukcje bez klamry przed scenariuszami takimi jak:

if (foo)
    snafu();
    bar();

Dzięki dobrym testom jednostkowym mogę śmiało pominąć nawiasy klamrowe w przypadku prostych instrukcji, aby poprawić czytelność (tak, to może być subiektywne).

Alternatywnie, w przypadku czegoś takiego jak powyżej, prawdopodobnie wstawiłbym to tak:

if (foo) snafu();

W ten sposób programista, który musi dodać bar () do warunku, byłby bardziej skłonny rozpoznać brak nawiasów klamrowych i dodać je.

Skorzystaj z własnego osądu.

if (foo)
  bar();

sam w sobie jest w porządku. Chyba że naprawdę martwisz się, że kretyni wprowadzą coś takiego później:

if (foo)
  bar();
  baz();

Jeśli nie martwisz się kretynami, nic ci nie jest (nie jestem - jeśli nie potrafią poprawnie uzyskać podstawowej składni kodu, to najmniejszy z ich problemów)>

W zamian jest dużo bardziej czytelny.

Resztę czasu:

if (foo) {
  bar();
  baz();
}

Który był moim ulubionym, odkąd pamiętam. Do tego:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Pracuje dla mnie.

Sama przestrzeń w pionie nie jest szczególnie istotna, ale czytelność jest. Nawias otwierający w wierszu sam w sobie zatrzymuje rozmowę o element składniowy, dopóki oko nie przejdzie do następnego wiersza. Nie to, co mi się podoba.

Okej, to jest stare pytanie, na które odpowiedziano na śmierć. Mam coś do dodania.

Najpierw muszę tylko powiedzieć, UŻYJ SZELEK. Mogą tylko pomóc w czytelności, a czytelność (dla ciebie i innych!) Powinna być bardzo wysoko na twojej liście priorytetów, chyba że piszesz asembler. Nieczytelny kod zawsze prowadzi do błędów. Jeśli okaże się, że nawiasy klamrowe powodują, że kod zajmuje zbyt dużo miejsca, Twoje metody są prawdopodobnie za długie. Większość lub wszystkie metody powinny mieścić się na jednej wysokości ekranu, jeśli robisz to dobrze, a Znajdź (F3) jest twoim przyjacielem.

Teraz do dodania: jest z tym problem:

if (foo) bar();

Spróbuj ustawić punkt przerwania, który zostanie uderzony tylko wtedy, gdy bar () ma zostać uruchomiony. Możesz to zrobić w C #, umieszczając kursor w drugiej połowie kodu, ale nie jest to oczywiste i jest trochę uciążliwe. W C ++ w ogóle nie można tego zrobić. Z tego powodu jeden z naszych najstarszych programistów pracujących nad kodem C ++ nalega na podzielenie instrukcji „if” na dwie linie. I zgadzam się z nim.

Więc zrób to:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}

aby kod z nawiasami klamrowymi nie zajmował dużo miejsca, stosuję technikę zalecaną w książce Code Complete :

if (...) {
    foo();
    bar();
}
else {
    ...
}

Powiedzmy, że masz kod:

if (foo)
    bar();

a potem ktoś inny podchodzi i dodaje:

if (foo)
    snafu();
    bar();

Zgodnie ze sposobem zapisu, bar (); jest teraz wykonywany bezwarunkowo. Uwzględniając nawiasy klamrowe, zapobiegasz tego rodzaju przypadkowym błędom. Kod powinien być napisany w taki sposób, aby takie błędy utrudniały lub uniemożliwiały ich popełnienie. Gdybym przeglądał kod i zobaczył brakujące nawiasy klamrowe, szczególnie rozmieszczone w wielu wierszach, utworzyłbym defekt. W przypadkach, gdy jest to uzasadnione, trzymaj go w jednym wierszu, aby szansa popełnienia takiego błędu była ponownie ograniczona do minimum.

Redukcja linii nie jest dobrym argumentem za porzuceniem nawiasów klamrowych. Jeśli Twoja metoda jest zbyt duża, prawdopodobnie powinna zostać ponownie podzielona na mniejsze części lub zrestrukturyzowana. Takie postępowanie bez wątpienia zwiększy czytelność bardziej niż zwykłe zdjęcie aparatu.

Zawsze je pomijam, gdy jest to stosowne, na przykład w twoim pierwszym przykładzie. Czysty, zwięzły kod, który widzę i rozumiem, patrząc na niego, jest łatwiejszy do utrzymania, debugowania i zrozumienia niż kod, który muszę przewijać i czytać wiersz po wierszu. Myślę, że większość programistów się z tym zgodzi.

Łatwo wymknąć się spod kontroli, jeśli zaczniesz wykonywać wiele zagnieżdżeń, klauzule if / else itd., Ale myślę, że większość programistów powinna być w stanie powiedzieć, gdzie narysować linię.

Widzę to tak jakby argument dla if ( foo == 0 )vs if ( 0 == foo ). Ta ostatnia może zapobiec błędom dla nowych programistów (a może nawet czasami dla weteranów), podczas gdy ta pierwsza jest łatwiejsza do odczytania i zrozumienia, gdy utrzymujesz kod.

W większości przypadków jest zakorzeniony jako standard kodowania, czy to dla firmy, czy dla projektu FOSS.

Ostatecznie ktoś inny będzie musiał zagłębić się w twój kod, a każdy programista musi spędzić dużo czasu, aby dowiedzieć się, jaki jest określony styl sekcji kodu, nad którym pracuje.

Wyobraź sobie również, że ktoś przechodzi między Pythonem a językiem Cish więcej niż raz dziennie ... W Pythonie wcięcia są częścią symantyki bloków tego języka i łatwo byłoby popełnić błąd podobny do tego, który zacytowałeś.

Po stronie bezpieczniejszego - jeszcze tylko jeden błąd, którego potencjalnie nie będziesz musiał naprawiać.

Osobiście czuję się bezpieczniej, jeśli wszystkie moje bloki są owinięte w kręcone. Nawet w przypadku jednowierszowych są to proste zapisy, które łatwo zapobiegają błędom. Sprawia, że ​​kod jest bardziej czytelny w tym sensie, że wyraźnie widzisz, co jest w bloku, aby nie mylić treści bloku z następującymi instrukcjami poza blokiem.

Jeśli mam jedną linijkę, zwykle formatuję ją w następujący sposób:

if( some_condition ) { do_some_operation; }

Jeśli linia jest po prostu zbyt uciążliwa, użyj następującego:

if( some_condition )
{
    do_some_operation;
}