Jeśli chodzi o konserwację, czy „else while” bez interwencji aparatów ortodontycznych jest uważane za bezpieczne?

Czy else whilebez interwencji aparatów ortodontycznych uważa się za „bezpieczną” konserwację?

Pisanie if-elsekodu bez nawiasów klamrowych jak poniżej ...

if (blah)
    foo();
else
    bar();

... niesie ryzyko, ponieważ brak nawiasów klamrowych sprawia, że ​​bardzo łatwo przypadkowo zmienić znaczenie kodu.

Czy jednak poniżej jest również ryzykowne?

if (blah)
{
    ...
}
else while (!bloop())
{
    bar();
}

Czy też else whilebez interwencji nawiasów klamrowych uważa się za „bezpieczny”?

To przypomina mi ten kod:

if ( ... ) try {
..
} catch (Exception e) {
..
} else {
...
}

Za każdym razem, gdy łączysz dwa rodzaje bloków, zapominając o nawiasach klamrowych i nie zwiększając wcięć, tworzysz kod bardzo trudny do zrozumienia i utrzymania.

Być może dzieje się tak, ponieważ nauczyłem się mojego handlu ( dawno temu) za pomocą metody Jackson Entity Structure Diagram , ale zgadzam się z poglądem, że jedynym poprawnym niehamowanym terminem po an iflub elsejest następna if(tj. Pozwalająca na else ifdrabinę)

Cokolwiek innego (bez zamierzonej gry słów) pozostawia możliwość nieporozumień i / lub problemów konserwacyjnych. To jest główny aspekt pomysłu PO jako „niebezpieczny”.

Byłbym również bardzo klatkowy, jeśli chodzi o umieszczenie linii while()na tej samej linii, co else- czy to na sztywno, czy nie. Nie odczytuje mnie to wprost ... brak dodatkowych masek wcięcia, że ​​jest to elseklauzula. A brak jasności powoduje nieporozumienia (patrz wyżej).

Dlatego w tym przykładzie zdecydowanie zalecam / polecam (i nalegam, w moim zespole) na:

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

Oczywiście oczekiwałbym również odpowiednich komentarzy.

-- Edytować --

Niedawno Apple ucierpiało z powodu luki w protokole SSL, spowodowanej słabą poprawką konserwacyjną - która dodała drugą linię do nieobjętej pojedynczej linii. A więc odłóżmy na bok pomysł, że pojedyncze nieskalowane linie są w porządku?

Zawsze uczono mnie trzymać wszystko w nawiasach klamrowych, wcięcia i komentarze. Uważam, że łatwiej jest odczytać i wykryć błędy. Osobiście uważam, że modułowość jest kluczem, więc zawsze pisałbym taki kod:

    if(blah)
    {
     ....
    }
    else
    {
       while(!bloop()
       {
        bar;
       }
    }

Chciałbym wyodrębnić metody i uczynić go

if ( blah )
{
    ...
}
else
{
   newMethod();
}

Zobacz „metodę ekstrakcji” wyjaśnioną na stronie katalogu refaktoryzacji :

Masz fragment kodu, który można zgrupować razem.

Zmień fragment w metodę, której nazwa wyjaśnia cel tej metody.

void printOwing() {
    printBanner();

    //print details
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + getOutstanding());
}

                                                                                                        

void printOwing() {
    printBanner();
    printDetails(getOutstanding());
}

void printDetails (double outstanding) {
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + outstanding);
}

Uznałbym to za zły nawyk kodowania. Czasami działa idealnie dobrze i nie będziesz mieć problemu z kompilacją i uruchomieniem kodu. W innych przypadkach może to powodować poważne błędy i będziesz spędzać godziny na naprawianiu tego błędu.

Zawsze zaleca się modularyzację kodu. Jeśli musisz umieścić pętlę while w innej części, umieść ją w bloku, aby inni podczas pracy nad twoim kodem mogli łatwo zrozumieć logikę.

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

Dobrą praktyką jest umieszczanie kodu w blokach. Ułatwia to także zrozumienie i debugowanie.

Może być dobrze, jeśli pozostanie takie proste, chociaż osobiście mi się to nie podoba i wolę używać nawiasów klamrowych nawet w najprostszych blokach kodu if / else. Dla mnie to po prostu porządniej.

Jednak tam, gdzie robi się bałagan, zagnieżdżasz się, jeśli / else zapętli niektóre z nawiasami klamrowymi bez nich. Pętla While w środku całego tego spaghetti! Tak źle pracowałem z kodem, a debugowanie i zrozumienie jest koszmarem. Wynika to z pierwszego punktu, że jest w porządku, gdy pozostaje prosty i jesteś z niego zadowolony, ale potem inni programiści przychodzą i dodają do niego różne rzeczy, prawdopodobnie jeśli jeszcze w obrębie pętli while. Jeśli jest napisane czysto, to szansa na to jest mniejsza.

Chodzi o to, aby wyjaśnić wszystko, aby inni programiści mogli zobaczyć na pierwszy rzut oka, co jest dobre, a co złe. Napisz kod, aby wzorzec wyglądał poprawnie i nie zgrzewał.

Drugą stroną tego jest to, że być może widziałem niektórych ludzi twierdzących, że w niektórych przypadkach brzmi to dobrze. Jeśli mam zasób, muszę wykonać to przetwarzanie jeszcze podczas oczekiwania na coś, zrób to. Nawet dla mnie nadal nie ma różnicy w zagnieżdżaniu pętli while w bloku else.

Cóż, pomimo tego, że wszyscy twierdzą, że używają aparatu ortodontycznego i wydają się je kochać, tak naprawdę wolę coś przeciwnego. Używam aparatu ortodontycznego tylko wtedy, gdy muszę, ponieważ uważam, że bez niego jest bardziej czytelny i zwięzły.

if (...)
   foo();
else while(...)
   bar();

... Właściwie uważam to za " else while(...)" wyjątkowo czytelne! To nawet brzmi jak zwykły angielski! Ale myślę, że ludzie uznają to za dziwne, ponieważ co najmniej niezwykłe.

W końcu wszyscy robimy to z idiotycznymi szelkami, ponieważ ... no wiesz.

Zawsze zakładam aparat ortodontyczny, tylko dlatego, że możesz dodać kolejną linię, gdy się spieszysz, wciąć ją, zapomnieć o aparatach ortodontycznych i podrapać się w głowę, co się dzieje. Trzymam klamrę otwierającą na tej samej linii, ale to nie ma znaczenia. W obu przypadkach lepiej je mieć.

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

Co jest takiego złego w aparatach ortodontycznych, że tak wiele osób próbuje ich unikać?

Jaki problem dokładnie else whilerozwiązuje?

Nawiasy klamrowe są tanie i dobre, a intencje kodu są oczywiste i jasne, w przeciwieństwie do sprytnych i dowcipnych.

Cytując filozofię Uniksa:

Reguła jasności: Klarowność jest lepsza niż spryt.

Ponieważ konserwacja jest tak ważna i tak droga, pisz programy, jakby najważniejszą komunikacją, jaką wykonują, nie był komputer, który je wykonuje, ale ludzie, którzy będą czytać i utrzymywać kod źródłowy w przyszłości (w tym ty sam).

Nie ma w tym nic złego

if (blah)
    foo();
else
    bar();

tak jak nie ma w tym nic złego

if (blah) foo(); else bar();

w odpowiednich okolicznościach (warunki mogą się różnić, ale ten konkretny styl najlepiej jest stosować, gdy masz dużo powtarzalnego kodu - wtedy widok każdej linii jest ważniejszy niż wcięcie stylistyczne)

Ale jeśli wybierzesz jeden sposób, trzymaj się go - spójność jest królem. Zatem twój drugi przykład jest bardzo zły, ponieważ jeśli wyrażenie zawiera nawiasy kwadratowe dla swojej instrukcji, instrukcja while powinna znajdować się w nawiasach dla klauzuli else, a nie poza nią.

poza tym widziałem ten kod wcześniej:

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

i został napisany przez samego kodującego nazistę (który nalegał na nawiasy na wszystko).

Nowoczesne IDE można łatwo skonfigurować w celu sformatowania (w tym usunięcia lub dodania niepotrzebnych nawiasów klamrowych) i / lub ponownego wpisania kodu przy zapisywaniu pliku. Twój przykład automatycznie wyglądałby na przykład

if (blah) {
  blub();
} else
  while (!bloop()) {
    bar();
  }

Wgłębienie zawsze sprawia, że ​​zagnieżdżanie jest dobrze widoczne, nawet bez zbędnych nawiasów klamrowych. Jeśli więc wymusisz takie ustawienia IDE, nie widzę żadnego ryzyka.

Osobiście uważam, że kod, który pomija nawiasy klamrowe i łamanie linii, jest bardziej czytelny, ponieważ pozwala uniknąć bałaganu:

if (blah) blub();
else while (!bloop()) bar();

Ale oczywiście wielu programistów bardzo chętnie kłóci się o takie rzeczy na zawsze i jeden dzień.