Jaki jest cel używania nawiasów klamrowych (tj. {}) Dla pojedynczej linii if lub loop?

Czytam notatki z wykładu mojego wykładowcy C ++, który napisał:

1. Użyj wcięcia // OK
2. Nigdy nie polegaj na pierwszeństwie operatora - zawsze używaj nawiasów // OK
3. Zawsze używaj bloku {} - nawet dla pojedynczej linii // nie OK , dlaczego ???
4. Stały obiekt po lewej stronie porównania // OK
5. Użyj bez znaku dla zmiennych, które są> = 0 // fajna sztuczka
6. Ustaw wskaźnik na NULL po usunięciu - Podwójna ochrona przed usunięciem // nieźle

Trzecia technika nie jest dla mnie jasna: co zyskałbym, umieszczając jedną linię w { ... }?

Weźmy na przykład ten dziwny kod:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

i zamień na:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

Jakie są zalety korzystania z 1. wersji?

Spróbujmy również zmodyfikować, igdy będziemy zwiększać j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

O nie! Pochodzący z Pythona wygląda to dobrze, ale w rzeczywistości tak nie jest, ponieważ jest równoważne z:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Oczywiście jest to głupi błąd, ale może popełnić go nawet doświadczony programista.

Kolejny bardzo dobry powód jest wskazany w odpowiedzi ta.speot.is .

Trzeci , o którym myślę, to zagnieżdżony if:

if (cond1)
   if (cond2) 
      doSomething();

Załóżmy, że chcesz teraz, doSomethingElse()kiedy cond1nie jest spełniony (nowa funkcja). Więc:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

co jest oczywiście błędne, ponieważ elsewiąże się z wewnętrznym if.

Edycja: Ponieważ przyciąga to trochę uwagi, wyjaśnię swój pogląd. Pytanie, na które odpowiadałem to:

Jakie są zalety korzystania z 1. wersji?

Które opisałem. Istnieje kilka korzyści. Ale IMO zasady „zawsze” nie zawsze mają zastosowanie. Więc nie w pełni popieram

Zawsze używaj bloku {} - nawet dla pojedynczej linii // nie OK, dlaczego ???

Nie mówię, że zawsze używaj {}bloku. Jeśli jest to dość prosty warunek i zachowanie, nie rób tego. Jeśli podejrzewasz, że ktoś może przyjść później i zmienić kod, aby dodać funkcjonalność, zrób to.

Bardzo łatwo jest przypadkowo zmienić przepływ kontroli z komentarzami, jeśli nie używasz {i }. Na przykład:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

Jeśli skomentujesz komentarz do_something_else()z jednym wierszem, skończysz na tym:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

Kompiluje się, ale must_always_do_this()nie zawsze jest wywoływane.

Mamy ten problem w naszej bazie kodu, gdzie ktoś wszedł, aby bardzo szybko wyłączyć niektóre funkcje przed wydaniem. Na szczęście złapaliśmy go podczas przeglądu kodu.

Mam wątpliwości co do kompetencji wykładowcy. Biorąc pod uwagę jego punkty:

1. ok
2. Czy ktoś naprawdę napisałby (lub chciałby przeczytać) (b*b) - ((4*a)*c) ? Niektóre pierwszeństwa są oczywiste (lub powinny być), a dodatkowe nawiasy tylko powodują zamieszanie. (Z drugiej strony, powinieneś używać nawiasów w mniej oczywistych przypadkach, nawet jeśli wiesz, że nie są one potrzebne).
3. Raczej. Istnieją dwie szeroko rozpowszechnione konwencje dotyczące formatowania warunków i pętli:

   if (cond) {
       kod;
   }
   

   i:

   if (cond)
   {
       kod;
   }
   

   Na początku zgodziłbym się z nim. Otwór {nie jest aż tak widoczny, więc najlepiej założyć, że zawsze tam jest. W drugim przypadku ja (i większość osób, z którymi pracowałem) nie mam problemu z pominięciem nawiasów klamrowych dla pojedynczej instrukcji. (Pod warunkiem, oczywiście, że wcięcie jest systematyczne i że konsekwentnie używasz tego stylu. (I wielu bardzo dobrych programistów, piszących bardzo czytelny kod, pomija nawiasy klamrowe nawet przy pierwszym formatowaniu).
4. NO . Takie rzeczy if ( NULL == ptr )są wystarczająco brzydkie, aby utrudnić czytelność. Pisz porównania intuicyjnie. (Co w wielu przypadkach powoduje stałą po prawej.) Jego 4 to zła rada; wszystko, co czyni kod nienaturalnym, czyni go mniej czytelnym.
5. NO . Wszystko, ale intjest zastrzeżone dla szczególnych przypadków. Dla doświadczonych programistów C i C ++ użycie unsignedoperatorów bitów sygnałów. C ++ nie ma prawdziwego typu kardynalnego (ani żadnego innego efektywnego typu podzakresu); unsignednie działa dla wartości liczbowych z powodu reguł promocji. Prawdopodobnie mogłyby to być wartości liczbowe, dla których żadne operacje arytmetyczne nie miałyby sensu, takie jak numery seryjne unsigned. Byłbym jednak przeciw temu, ponieważ wysyła niewłaściwy komunikat: operacje bitowe również nie mają sensu. Podstawową zasadą jest to, że typy całkowe są int, o ile nie ma istotnego powodu, aby używać innego typu.
6. NO . Robienie tego systematycznie jest mylące i właściwie nie chroni przed niczym. W ścisłym kodu OO, delete this;często jest najczęstszy przypadek (i nie można ustawić thisdo NULL), a inaczej, najbardziej deletesą destruktory, więc nie można uzyskać dostępu wskaźnik później tak. Ustawienie tej opcji NULLnie ma wpływu na żadne inne wskaźniki unoszące się wokół. Systematyczne ustawianie wskaźnika NULLdaje fałszywe poczucie bezpieczeństwa i tak naprawdę nic nie kupuje.

Spójrz na kod w jednym z typowych odniesień. Stroustrup narusza każdą podaną przez ciebie regułę, z wyjątkiem pierwszej, na przykład.

Proponuję znaleźć innego wykładowcę. Ten, który tak naprawdę wie o czym mówi.

Wszystkie pozostałe odpowiedzi bronią zasady twojego wykładowcy 3.

Powiem, że się z tobą zgadzam: zasada jest zbędna i nie radziłbym jej. To prawda, że teoretycznie zapobiega błędom, jeśli zawsze dodajesz nawiasy klamrowe. Z drugiej strony nigdy nie spotkałem tego problemu w prawdziwym życiu : wbrew temu, co sugerują inne odpowiedzi, nie zapomniałem dodać nawiasów klamrowych, gdy stały się konieczne. Jeśli użyjesz odpowiedniego wcięcia, natychmiast stanie się oczywiste, że musisz dodać nawiasy klamrowe po wcięciu więcej niż jednego wyrażenia.

Odpowiedź „komponentu 10” w rzeczywistości podkreśla jedyny możliwy przypadek, w którym może to naprawdę prowadzić do błędu. Ale z drugiej strony zastąpienie kodu wyrażeniem regularnym zawsze wymaga ogromnej uwagi.

Spójrzmy teraz na drugą stronę medalu: czy jest wada, aby zawsze używać nawiasów klamrowych? Inne odpowiedzi po prostu ignorują ten punkt. Ale jest to wadą: to zajmuje dużo przestrzeni pionowej ekranu, a to z kolei może spowodować, że kod nieczytelny, ponieważ oznacza to, że trzeba przejść więcej niż to konieczne.

Rozważ funkcję z wieloma klauzulami ochronnymi na początku (i tak, poniższy kod jest zły C ++, ale w innych językach byłaby to dość powszechna sytuacja):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

To okropny kod i zdecydowanie argumentuję, że następujące elementy są znacznie bardziej czytelne:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

Podobnie krótkie zagnieżdżone pętle korzystają z pominięcia nawiasów klamrowych:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

Porównać z:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

Pierwszy kod jest zwięzły; drugi kod jest wzdęty.

I tak, można to w pewnym stopniu złagodzić, umieszczając nawias otwierający w poprzedniej linii. Ale tak by było było byłoby mniej czytelne niż kod bez nawiasów klamrowych.

W skrócie: nie pisz niepotrzebnego kodu, który zajmuje miejsce na ekranie.

Baza kodu, nad którym pracuję, jest rozproszona z kodem przez ludzi z patologiczną niechęcią do nawiasów klamrowych, a dla ludzi, którzy przyjdą później, naprawdę może to mieć wpływ na łatwość konserwacji.

Najczęstszym problematycznym przykładem, z jakim się spotkałem, jest:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

Więc kiedy przychodzę i chcę dodać oświadczenie wtedy, mogę z łatwością skończyć z tym, jeśli nie jestem ostrożny:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

Biorąc pod uwagę, że dodanie nawiasów zajmuje ~ 1 sekundę i może zaoszczędzić co najmniej kilka zdezorientowanych minut debugowania, dlaczego nigdy nie miałbyś skorzystać z opcji zmniejszonej dwuznaczności? Wydaje mi się to fałszywą ekonomią.

Mój 2c:

Użyj wcięcia

Oczywiście

Nigdy nie polegaj na pierwszeństwie operatora - zawsze używaj nawiasów

Nie używałbym słów „nigdy” i „zawsze”, ale ogólnie rzecz biorąc widzę, że ta zasada jest przydatna. W niektórych językach (Lisp, Smalltalk) nie jest to problemem.

Zawsze używaj bloku {} - nawet dla pojedynczej linii

Nigdy tego nie robię i nigdy nie miałem ani jednego problemu, ale widzę, jak to może być dobre dla studentów, szczególnie. jeśli wcześniej studiowali Python.

Stały obiekt po lewej stronie porównania

Warunki Yoda? Nie prosze Utrudnia to czytelność. Wystarczy użyć maksymalnego poziomu ostrzeżenia podczas kompilacji kodu.

Użyj bez znaku dla zmiennych, które są> = 0

OK. Zabawne, słyszałem, że Stroustrup się nie zgadza.

Ustaw wskaźnik na NULL po usunięciu - ochrona przed podwójnym usunięciem

Zła rada! Nigdy nie używaj wskaźnika, który wskazuje na usunięty lub nieistniejący obiekt.

jest bardziej intuicyjny i łatwo zrozumiały. Wyjaśnia to intencję.

I zapewnia, że ​​kod nie zostanie złamany, gdy nowy użytkownik może nieświadomie przegapić {, }dodając nową instrukcję kodu.

Aby dodać do bardzo rozsądnych sugestii powyżej, jeden przykład, który napotkałem podczas refaktoryzacji kodu, w którym staje się on krytyczny, był następujący: Zmieniłem bardzo dużą bazę kodu, aby przełączyć się z jednego interfejsu API na inny. Pierwszy interfejs API miał wywołanie w celu ustawienia identyfikatora firmy w następujący sposób:

setCompIds( const std::string& compId, const std::string& compSubId );

mając na uwadze, że wymiana wymagała dwóch połączeń:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

Zacząłem to zmieniać za pomocą wyrażeń regularnych, co było bardzo udane. Przekazaliśmy również kod przez astyle , co naprawdę uczyniło go o wiele bardziej czytelnym. Następnie, w połowie procesu recenzji, odkryłem, że w pewnych warunkowych okolicznościach zmienia to:

if ( condition )
   setCompIds( compId, compSubId );

Do tego:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

co wyraźnie nie jest tym, co było wymagane. Musiałem wrócić do początku, zrób to jeszcze raz, traktując zamiennik jako całkowicie w bloku, a następnie ręcznie zmieniając wszystko, co skończyło się na głupkowatym (przynajmniej nie byłoby to nieprawidłowe).

Zauważam, że astyle ma teraz opcję, --add-bracketsktóra pozwala dodawać nawiasy kwadratowe tam, gdzie ich nie ma, i zdecydowanie polecam to, jeśli kiedykolwiek znajdziesz się w tej samej pozycji, co ja.

Używam {}wszędzie, z wyjątkiem kilku przypadków, w których jest to oczywiste. Jedna linia to jeden z przypadków:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

To może cię zranić, jeśli dodasz jakąś metodę przed powrotem. Wcięcie wskazuje, że powrót jest wykonywany, gdy warunek jest spełniony, ale zawsze będzie zwracany.

Inny przykład w C # z użyciem statment

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

co jest równoważne z

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

Najbardziej trafny przykład, jaki mogę wymyślić:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

Z ifczym elsezostanie sparowany? Wcięcie oznacza, że ​​zewnętrzny ifpobiera else, ale tak naprawdę kompilator tego nie zobaczy; wewnętrzny if dostanie else, a zewnętrzna ifnie. Musisz wiedzieć, że (lub zobaczyć, jak zachowuje się w ten sposób w trybie debugowania), aby dowiedzieć się, sprawdzając, dlaczego ten kod może nie spełniać twoich oczekiwań. Staje się bardziej mylące, jeśli znasz Python; w takim przypadku wiesz, że wcięcie definiuje bloki kodu, więc można oczekiwać, że będzie ono obliczane zgodnie z wcięciem. C # nie daje jednak latającego przewrotu na temat białych znaków.

To powiedziawszy, nie zgadzam się szczególnie z tą zasadą „zawsze używaj nawiasów” na jej twarzy. Powoduje to, że kod jest bardzo głośny w pionie, co zmniejsza jego zdolność do szybkiego czytania. Jeśli oświadczenie brzmi:

if(someCondition)
   DoSomething();

... to powinno być tak napisane. Stwierdzenie „zawsze używaj nawiasów” brzmi jak „zawsze otaczaj operacje matematyczne nawiasami”. To przekształciłoby bardzo proste stwierdzenie a * b + c / dw ((a * b) + (c / d)), wprowadzając możliwość pominięcia ścisłego paren (zmorę wielu koderów) i po co? Kolejność operacji jest dobrze znana i egzekwowana, dlatego nawiasy są zbędne. Używałbyś nawiasów tylko w celu wymuszenia innej kolejności operacji niż normalnie stosowane: a * (b+c) / dna przykład. Blokowe nawiasy klamrowe są podobne; użyj ich, aby zdefiniować, co chcesz robić w przypadkach, w których różni się od domyślnego i nie jest „oczywisty” (subiektywny, ale zazwyczaj zdrowy rozsądek).

Przeglądając odpowiedzi, których nikt nie określił, jakiego rodzaju praktykę używam, opowiadając historię twojego kodu:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

Staje się:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

Kładzenie j++się na tej samej linii jak gdyby sygnał nikomu innemu, „Chcę tylko tego bloku kiedykolwiek przyrostu j” . Z coursethis ma sens tylko wtedy, gdy linia jest tak proste, jak to możliwe, bo oddanie przerwania tutaj, jak peri wspomina, nie będzie bardzo przydatna.

W rzeczywistości właśnie natknąłem się na część interfejsu API Twitter Storm, która zawiera ten „rodzaj” kodu w java, oto fragment relatywny z kodu wykonawczego, na stronie 43 tego pokazu slajdów :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

Blok pętli for ma w sobie dwie rzeczy, więc nie wstawiłbym tego kodu. Tj. Nigdy :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

To okropne i nawet nie wiem, czy to działa (zgodnie z przeznaczeniem); nie rób tego . Nowe linie i nawiasy klamrowe pomagają rozróżnić oddzielne, ale powiązane fragmenty kodu, w taki sam sposób, jak przecinek lub średnik w prozie. Powyższy blok jest równie kiepski, naprawdę długie zdanie z kilkoma klauzulami i kilkoma innymi stwierdzeniami, które nigdy nie łamią się ani nie przerywają, aby rozróżnić poszczególne części.

Jeśli naprawdę chcesz telegrafować do kogoś innego, jest to praca tylko w jednym wierszu, użyj operatora trójskładnikowego lub ?:formularza:

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

Ale to jest na granicy golfa kodowego i myślę, że nie jest to świetna praktyka (nie jest dla mnie jasne, czy powinienem umieścić j ++ po jednej stronie, :czy nie). NB: Nie korzystałem wcześniej z trójkowego operatora w C ++, nie wiem czy to działa, ale tak jest .

W skrócie:

Wyobraź sobie, jak twój czytelnik (tj. Osoba obsługująca kod) interpretuje twoją historię (kod). Wyjaśnij im, jak to możliwe. Jeśli wiesz, że początkujący programista / uczeń utrzymuje to, być może nawet zostaw tak wiele, {}jak to możliwe, tylko po to, aby się nie pomylić.

Ponieważ bez dwóch stwierdzeń {}łatwo jest przeoczyć problem. Załóżmy, że kod wygląda tak.

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

To wygląda dobrze. Problem z tym jest naprawdę łatwy do przeoczenia, szczególnie gdy funkcja zawierająca kod jest znacznie większa. Problem polega na tym, że goto failjest prowadzony bezwarunkowo. Możesz łatwo wyobrazić sobie, jak to jest frustrujące (co powoduje, że pytasz, dlaczego ostatni hash_updatezawsze zawodzi, w końcu wszystko hash_updatedziała dobrze ).

Nie oznacza to jednak, że jestem za dodawaniem {}wszędzie (moim zdaniem widzenie {}wszędzie jest denerwujące). Chociaż może powodować problemy, nigdy nie robił tego w przypadku moich własnych projektów, ponieważ mój osobisty styl kodowania zabrania warunkowych bez, {}gdy nie są na tej samej linii (tak, zgadzam się, że mój styl kodowania jest niekonwencjonalny, ale podoba mi się i używaj stylu kodu projektu, gdy współtworzysz inne projekty). To sprawia, że ​​następujący kod jest w porządku.

if (something) goto fail;

Ale nie następna.

if (something)
    goto fail;

Sprawia, że ​​kod jest bardziej czytelny, dzięki wyraźnemu zdefiniowaniu zakresu pętli i bloków warunkowych. Oszczędza to również przed przypadkowymi błędami.

wrt 6: Jest to bezpieczniejsze, ponieważ usunięcie wskaźnika zerowego nie jest możliwe. Jeśli przypadkowo przypadkowo przejdziesz tę ścieżkę dwa razy, nie spowoduje to, że uszkodzenie pamięci spowoduje zwolnienie pamięci, która jest wolna lub została przydzielona na coś innego.

Jest to większość problemu ze statycznymi obiektami zakresu plików i singletonami, które nie mają bardzo jasnego czasu życia i które zostały odtworzone po ich zniszczeniu.

W większości przypadków możesz tego uniknąć, używając auto_ptrs

Podoba mi się zaakceptowana odpowiedź Luchiana, w rzeczywistości nauczyłem się na własnej skórze, że ma rację, więc zawsze używam nawiasów klamrowych, nawet dla bloków jednowierszowych. Jednak osobiście robię wyjątek, pisząc filtr, tak jak w twoim przykładzie. To:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

wygląda na zagracony dla mnie. Oddziela pętlę for i instrukcję if na osobne akcje, podczas gdy tak naprawdę twoja intencja jest pojedynczą akcją: policzyć wszystkie liczby całkowite podzielne przez 2. W bardziej wyrazistym języku można to napisać w następujący sposób:

j = [1..100].filter(_%2 == 0).Count

W językach, w których brakuje zamknięć, filtr nie może być wyrażony w pojedynczej instrukcji, ale musi być pętlą for, po której następuje instrukcja if. Jest to jednak jedno działanie w umyśle programisty i uważam, że powinno to zostać odzwierciedlone w kodzie, tak jak poniżej:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

Jedną z opcji zapobiegania błędom opisanym powyżej jest podkreślenie tego, co chcesz się wydarzyć, gdy nie używasz nawiasów klamrowych. Znacznie trudniej jest nie zauważyć błędów podczas próby modyfikacji kodu.

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

Jeśli jesteś kompilatorem, nie robi to żadnej różnicy. Oba są takie same.

Ale dla programistów pierwszy jest bardziej przejrzysty, czytelny i mniej podatny na błędy.

Kolejny przykład dodawania nawiasów klamrowych. Kiedyś szukałem błędu i znalazłem taki kod:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

Jeśli czytasz metodę wiersz po wierszu, zauważysz, że w metodzie występuje warunek, który zwraca wartość, jeśli nie jest to prawda. Ale tak naprawdę wygląda to na 100 innych prostych procedur obsługi zdarzeń, które ustawiają niektóre zmienne na podstawie pewnych warunków. I pewnego dnia pojawia się Fast Coder i dodaje dodatkowe oświadczenie o zmiennej wartości na końcu metody:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

W rezultacie SetAnotherVariableUnconditionnaly jest wykonywana, gdy SomeConditionIsMet (), ale szybki facet tego nie zauważył, ponieważ wszystkie linie mają prawie podobny rozmiar, a nawet gdy warunek powrotu jest wcięty pionowo, nie jest to tak zauważalne.

Jeśli warunkowy zwrot jest sformatowany w następujący sposób:

if (!SomeConditionIsMet())
{
    return;
}

jest to zauważalne, a szybki koder znajdzie to na pierwszy rzut oka.

Pierwszy uważam za jasny, a następnie drugi. Daje to wrażenie zamykania instrukcji, ponieważ mały kod jest w porządku, gdy kod staje się skomplikowany, bardzo {...}pomaga, nawet jeśli jest endiflubbegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Po zakończeniu najlepiej ustawić wskaźnik na NULL.

Oto przykład, dlaczego:

Klasa A wykonuje następujące czynności:

1. Przydziela blok pamięci
2. Potem jakiś czas usuwa ten blok pamięci, ale nie ustawia wskaźnika na NULL

Klasa B wykonuje następujące czynności

1. Przydziela pamięć (w tym przypadku zdarza się, że otrzymuje ten sam blok pamięci, który został usunięty przez klasę A.)

W tym momencie zarówno klasa A, jak i klasa B mają wskaźniki wskazujące na ten sam blok pamięci, jeśli chodzi o klasę A, ten blok pamięci nie istnieje, ponieważ jest z nim zakończony.

Rozważ następujący problem:

Co jeśli wystąpił błąd logiczny w klasie A, który spowodował zapisanie go w pamięci, która teraz należy do klasy B?

W tym konkretnym przypadku nie wystąpi błąd wyjątku złego dostępu, ponieważ adres pamięci jest legalny, a klasa A skutecznie uszkadza dane klasy B.

Klasa B może ostatecznie upaść, jeśli napotka nieoczekiwane wartości, a kiedy się zawiesi, są szanse, że spędzisz dość dużo czasu na polowaniu na tego błędu w klasie B, gdy problem występuje w klasie A.

Jeśli ustawisz wskaźnik usuniętej pamięci na NULL, otrzymasz błąd wyjątku, gdy tylko jakiekolwiek błędy logiczne w klasie A spróbują zapisać do wskaźnika NULL.

Jeśli martwisz się błędem logicznym podwójnego usuwania, gdy wskaźniki po raz drugi mają wartość NULL, dodaj dla tego potwierdzenie.

Ponadto: jeśli zamierzasz obniżyć głosowanie, wyjaśnij to.

Zawsze posiadanie nawiasów klamrowych jest bardzo prostą i niezawodną zasadą. Jednak kod może wyglądać nieelegancko, gdy jest wiele nawiasów klamrowych. Jeśli reguły pozwalają pominąć nawiasy klamrowe, powinny istnieć bardziej szczegółowe reguły stylu i bardziej wyrafinowane narzędzia. W przeciwnym razie może łatwo powstać chaotyczny i mylący (nie elegancki) kod. Dlatego szukanie reguły pojedynczego stylu oddzielnie od pozostałych przewodników stylu i używanych narzędzi jest prawdopodobnie bezowocne. Przedstawię tylko kilka ważnych szczegółów dotyczących tej zasady nr 3, o których nawet nie wspomniano w innych odpowiedziach.

Pierwszym interesującym szczegółem jest to, że większość zwolenników tej zasady zgadza się na jej naruszenie w przypadku else. Innymi słowy, nie wymagają przeglądu takiego kodu:

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

Zamiast tego, jeśli go zobaczą, mogą nawet zasugerować, aby napisać w ten sposób:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

Jest to technicznie naruszenie tej zasady, ponieważ nie ma nawiasów klamrowych między elsei if. Taka dwoistość reguły ujawnia się, kiedy należy zastosować ją automatycznie do bazy kodu za pomocą bezmyślnego narzędzia. Rzeczywiście, po co się kłócić, po prostu pozwól narzędziu automatycznie zastosować styl.

Drugi szczegół (który jest również często zapominany przez zwolenników tej reguły) jest taki, że błędy, które mogą się zdarzyć, nigdy nie są spowodowane jedynie naruszeniem tej zasady # 3. W rzeczywistości prawie zawsze wiążą się z naruszeniem reguły nr 1 (z którą nikt się nie kłóci). Ponownie, z punktu widzenia automatycznych narzędzi, nie jest trudno stworzyć narzędzie, które natychmiast narzeka, gdy naruszona zostanie reguła nr 1, dzięki czemu większość błędów można wychwycić na czas.

Trzecim szczegółem (często zapominanym przez przeciwników tej reguły) jest myląca natura pustego wyrażenia reprezentowanego przez pojedynczy średnik. Większość programistów z pewnym doświadczeniem prędzej czy później pomyliło się z powodu jednoznacznie umieszczonego średnika lub pustej instrukcji napisanej przy użyciu jedynego średnika. Dwa nawiasy klamrowe zamiast pojedynczego średnika są znacznie łatwiejsze do zauważenia.

Muszę przyznać, że nie zawsze używa się go {}na pojedynczej linii, ale to dobra praktyka.

• Powiedzmy, że piszesz kod bez nawiasów, który wygląda następująco:

  for (int i = 0; i <100; ++ i) for (int j = 0; j <100; ++ j) DoSingleStuff ();

A po pewnym czasie chcesz dodać w jpętli inne rzeczy i po prostu to zrobić, wyrównując i zapomnieć o dodawaniu nawiasów.

• Przydział pamięci jest szybszy. Powiedzmy, że masz duży zakres i tworzysz duże tablice wewnątrz (bez, newwięc są one w stosie). Te tablice usuwają się z pamięci tuż po opuszczeniu zakresu. Ale możliwe jest, że użyjesz tej tablicy w jednym miejscu i będzie ona przez pewien czas w stosie i będzie czymś w rodzaju śmieci. Ponieważ stos ma ograniczony i dość mały rozmiar, można go przekroczyć. Dlatego w niektórych przypadkach lepiej jest pisać, {}aby temu zapobiec. UWAGA nie dotyczy pojedynczej linii, ale takich sytuacji:

  if (...) {// SomeStuff ... {// nie mamy, jeśli, podczas, itp. // SomeOtherStuff} // SomeMoreStuff}

• Trzeci sposób użycia jest podobny do drugiego. To po prostu nie ma na celu uczynienia stosu czystszym, ale otwarcie niektórych funkcji. Jeśli używasz mutexdługich funkcji, zwykle lepiej jest zablokować i odblokować tuż przed uzyskaniem dostępu do danych i zaraz po zakończeniu ich odczytu / zapisu. UWAGA ten sposób jest używany, jeśli masz własne classlub structz constructori destructordo blokowania pamięci.

• Co więcej:

  if (...) if (...) SomeStuff (); else SomeOtherStuff (); // przechodzi do drugiego jeśli, ale przydział pokazuje, że jest on pierwszy ...

Podsumowując, nie mogę powiedzieć, jaki jest najlepszy sposób, aby zawsze używać {}pojedynczej linii, ale nie jest to nic złego.

WAŻNA EDYCJA Jeśli napiszesz nawiasy kompilujące kod dla pojedynczej linii, nic nie robi, ale jeśli twój kod zostanie zinterpretowany, bardzo nieznacznie spowalnia kod. Bardzo nieznacznie.

Istnieje wiele możliwych sposobów pisania instrukcji kontrolnych; niektóre ich kombinacje mogą współistnieć bez pogorszenia czytelności, ale inne kombinacje powodują problemy. Styl

if (condition)
  statement;

będzie współistnieć wygodnie z niektórymi innymi sposobami pisania instrukcji kontrolnych, ale nie tak dobrze z innymi. Jeśli instrukcje sterowane wieloliniowo są zapisywane jako:

if (condition)
{
  statement;
  statement;
}

wtedy wizualnie będzie oczywiste, które ifinstrukcje kontrolują jedną linię, a które kontrolują wiele linii. Jeśli jednak ifwyrażenia wieloliniowe są zapisywane jako:

if (condition) {
  statement;
  statement;
}

wtedy prawdopodobieństwo, że ktoś spróbuje rozszerzyć konstrukcję pojedynczej instrukcji ifbez dodania niezbędnych nawiasów klamrowych, może być znacznie wyższe.

Instrukcja pojedynczego wyrażenia w następnym wierszu ifmoże być również problematyczna, jeśli baza kodów w znacznym stopniu korzysta z formularza

if (condition) statement;

Osobiście wolę, aby posiadanie instrukcji we własnej linii ogólnie poprawiało czytelność, z wyjątkiem przypadków, gdy istnieje wiele ifinstrukcji z podobnymi blokami kontrolnymi, np.

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

w takim przypadku zwykle poprzedzam i podążam za takimi grupami ifinstrukcji pustą linią, aby wizualnie oddzielić je od innych kodów. Posiadanie szeregu stwierdzeń rozpoczynających się ifod tego samego wcięcia zapewni wyraźne wizualne wskazanie, że istnieje coś niezwykłego.