Deweloper twierdzi, że instrukcje nie powinny mieć zanegowanych warunków i zawsze powinny mieć inny blok

Mam znajomego, bardziej doświadczonego programistę niż ja. Rozmawialiśmy o praktykach programistycznych i zaskoczyło mnie jego podejście do wypowiedzi „jeśli”. Nalega na pewne praktyki dotyczące stwierdzeń, które uważam za dość dziwne.

Po pierwsze , po instrukcji if powinna następować instrukcja else, niezależnie od tego, czy jest coś do wprowadzenia, czy nie. Co prowadzi do kodu wyglądającego tak:

if(condition) 
{
    doStuff();
    return whatever;
}
else
{
}

Po drugie , lepiej jest sprawdzić prawdziwe wartości niż fałsz. Oznacza to, że lepiej jest przetestować zmienną „doorClosed” zamiast zmiennej „! DoorOpened”

Jego argumentem jest to, że sprawia, że jaśniejsze co kod robi.

Co mnie trochę dezorientuje, ponieważ połączenie tych dwóch reguł może doprowadzić go do napisania tego rodzaju kodu, jeśli chce coś zrobić, gdy warunek nie jest spełniony.

if(condition)
{
}
else
{
    doStuff();
    return whatever;
}

Mam wrażenie, że jest to naprawdę brzydkie i / lub poprawa jakości, jeśli w ogóle, jest znikoma. Ale jako junior jestem skłonny wątpić w mój instynkt.

Więc moje pytania brzmią: czy jest to dobra / zła / „nieważna” praktyka? Czy to powszechna praktyka?

Jawny elseblok

Pierwsza reguła po prostu zanieczyszcza kod i sprawia, że ​​nie jest on ani bardziej czytelny, ani mniej podatny na błędy. Przypuszczam, że celem twojego kolegi jest wyraźne, pokazując, że programista był w pełni świadomy, że warunek może się ocenić false. Chociaż dobrze jest być jawnym, taka jawność nie powinna kosztować trzech dodatkowych wierszy kodu .

Nie wspominam nawet o tym, że po ifoświadczeniu niekoniecznie musi elseznajdować się „ albo” albo „nic”: może też następować jeden lub więcej elif.

Obecność returnoświadczenia pogarsza sytuację. Nawet jeśli faktycznie masz kod do wykonania w elsebloku, bardziej zrozumiałe będzie wykonanie tego w następujący sposób:

if (something)
{
    doStuff();
    return whatever;
}

doOtherThings();
return somethingElse;

To sprawia, że ​​kod zajmuje dwa wiersze mniej, i odradza elseblok. Chodzi o klauzule ochronne .

Zauważ jednak, że technika twojego kolegi może częściowo rozwiązać bardzo nieprzyjemny wzór ułożonych bloków warunkowych bez spacji:

if (something)
{
}
if (other)
{
}
else
{
}

W poprzednim kodzie brak rozsądnego podziału linii po pierwszym ifbloku bardzo łatwo źle interpretuje kod. Jednak chociaż reguła twojego kolegi utrudniłaby błędne odczytanie kodu, łatwiejszym rozwiązaniem byłoby po prostu dodanie nowego wiersza.

Testuj true, a niefalse

Druga reguła może mieć jakiś sens, ale nie w obecnej formie.

Nie jest prawdą, że testowanie drzwi zamkniętych jest bardziej intuicyjne niż testowanie drzwi nieotwartych . Negacje, a zwłaszcza negacje zagnieżdżone, są zwykle trudne do zrozumienia:

if (!this.IsMaster || (!this.Ready && !this.CanWrite))

Aby rozwiązać ten problem, zamiast dodawać puste bloki, utwórz dodatkowe właściwości, w stosownych przypadkach, lub zmienne lokalne .

Powyższy warunek można dość łatwo odczytać:

if (this.IsSlave || (this.Synchronizing && this.ReadOnly))

Jeśli chodzi o pierwszą zasadę, jest to przykład bezużytecznego pisania. Pisanie nie tylko zajmuje więcej czasu, ale powoduje ogromne zamieszanie dla osób czytających kod. Jeśli kod nie jest potrzebny, nie pisz go. Obejmuje to nawet brak wypełnienia elsew twoim przypadku, gdy kod wraca z ifbloku:

if(condition) 
{
    doStuff();
    return whatever;
}

doSomethingElse(); // no else needed
return somethingelse;

Jeśli chodzi o drugi punkt, dobrze jest unikać nazw boolowskich zawierających negatywne:

bool doorNotOpen = false; // a double negative is hard to reason
bool doorClosed = false; // this is much clearer

Jednak, jak zauważyłeś, rozszerzenie tego zakresu na brak testowania negatywu prowadzi do bardziej bezużytecznego pisania. Poniższe jest o wiele wyraźniejsze niż posiadanie pustego ifbloku:

if(!condition)
{
    doStuff();
    return whatever;
}

1. Argument za pustymi elsestwierdzeniami.

Często używam (i argumentuję) czegoś podobnego do tego pierwszego konstruktu, pustego innego. Sygnalizuje to czytelnikom kodu (zarówno ludzkim, jak i automatycznym narzędziom analitycznym), że programista zastanowił się nad sytuacją. Brakujące elseoświadczenia, które powinny być obecne, zabijały ludzi, rozbijały pojazdy i kosztowały miliony dolarów. Na przykład MISRA-C nakazuje przynajmniej komentarz stwierdzający, że brakujący finał jest celowy w if (condition_1) {do_this;} else if (condition_2) {do_that;} ... else if (condition_n) {do_something_else;}sekwencji. Inne standardy wysokiej niezawodności idą nawet dalej: z kilkoma wyjątkami, brak innych instrukcji jest zabronione.

Jednym wyjątkiem jest prosty komentarz, coś podobnego do /* Else not required */. Sygnalizuje to ten sam cel, co trzy linie puste. Kolejnym wyjątkiem, w którym to puste miejsce nie jest potrzebne, jest oczywiste zarówno dla czytelników kodu, jak i dla automatycznych narzędzi analitycznych, które to puste zbędne. Na przykład if (condition) { do_stuff; return; }Podobnie puste pole nie jest potrzebne w przypadku throw somethinglub goto some_label¹ zamiast return.

2. Argument za preferowanie if (condition)ponad if (!condition).

To jest czynnik ludzki. Złożona logika boolowska wprawia w ruch wiele osób. Nawet doświadczony programista będzie musiał pomyśleć if (!(complex || (boolean && condition))) do_that; else do_this;. Przynajmniej przepisz to jako if (complex || (boolean && condition)) do_this; else do_that;.

3. Nie oznacza to, że należy preferować puste thenstwierdzenia.

Druga sekcja mówi „wolisz” niż „powinieneś”. Jest to raczej wytyczna niż reguła. Powodem, dla którego wytyczne te preferują pozytywne ifwarunki, jest to, że kod powinien być jasny i oczywisty. Klauzula pusta wtedy (np. if (condition) ; else do_something;) Narusza to. Jest to zaciemnione programowanie, które powoduje, że nawet najbardziej doświadczeni programiści wykonują kopie zapasowe i ponownie czytają ifstan w negowanej formie. Więc napisz to w negacji w pierwszej kolejności i pomiń instrukcję else (lub miej puste pole else lub komentarz na ten temat, jeśli jest do tego upoważniony).

¹ pisałem, że wtedy klauzule, które kończą się return, throwczy gotonie wymagają pusty indziej. Oczywiste jest, że klauzula else nie jest potrzebna. Ale co z goto? Nawiasem mówiąc, zasady programowania krytyczne dla bezpieczeństwa czasami zabraniają wczesnego powrotu i prawie zawsze nie dopuszczają wyjątków. Pozwalają jednak gotona to w ograniczonej formie (np goto cleanup1;.). To ograniczone użycie gotojest preferowaną praktyką w niektórych miejscach. Na przykład jądro Linuksa jest pełne takich gotoinstrukcji.

Używam pustej gałęzi else (a czasem pustej gałęzi if) w bardzo rzadkich przypadkach: gdy jest oczywiste, że zarówno część if, jak i część powinny być obsługiwane w jakiś sposób, ale z jakiegoś nietrywialnego powodu sprawa może być obsługiwana przez nic nie robić. Dlatego każdy, kto czyta kod z koniecznym działaniem else, natychmiast podejrze, że czegoś brakuje i zmarnuje swój czas.

if (condition) {
    // No action needed because ...
} else {
    do_else_action()
}

if (condition) {
    do_if_action()
} else {
    // No action needed because ...
}

Ale nie:

if (condition) {
    do_if_action()
} else {
    // I was told that an if always should have an else ...
}

Wszystkie pozostałe są równe, wolę zwięzłość.

Czego nie piszesz, nikt nie musi czytać i rozumieć.

Chociaż wyraźne może być przydatne, dzieje się tak tylko wtedy, gdy bez nadmiernej gadatliwości stanie się oczywiste, że to, co napisałeś, jest naprawdę tym, co chciałeś napisać.

Unikaj więc pustych gałęzi, są one nie tylko bezużyteczne, ale także rzadkie i prowadzą do zamieszania.

Unikaj także pisania gałęzi else, jeśli wyjdziesz bezpośrednio z gałęzi if.

Przydatnym zastosowaniem jawności byłoby umieszczenie komentarza za każdym razem, gdy przejdziemy przez skrzynkę przełączników // FALLTHRU, oraz użycie komentarza lub pustego bloku, w którym potrzebujesz pustej instrukcji for(a;b;c) /**/;.

Według mojej wiedzy nie ma twardych i szybkich zasad dotyczących pozytywnych lub negatywnych warunków dla instrukcji IF. Osobiście wolę kodowanie dla przypadku pozytywnego niż negatywnego, w stosownych przypadkach. Z pewnością tego nie zrobię, jeśli doprowadzi mnie to do utworzenia pustego bloku JEŻELI, po którym następuje ELSE pełen logiki. Gdyby taka sytuacja się pojawiła, zajęłoby to 3 sekundy, aby powrócić do testowania pod kątem pozytywnego przypadku.

To, co naprawdę nie lubię w twoich przykładach, to całkowicie niepotrzebna przestrzeń pionowa zajmowana przez pusty ELSE. Po prostu nie ma po temu żadnego powodu. Nie dodaje niczego do logiki, nie pomaga dokumentować tego, co robi kod, i wcale nie zwiększa czytelności. W rzeczywistości argumentowałbym, że dodana przestrzeń pionowa mogłaby prawdopodobnie zmniejszyć czytelność.

Jawny elseblok

Nie zgadzam się z tym jako ogólne stwierdzenie obejmujące wszystkie ifstwierdzenia, ale zdarza się, że dodanie elsebloku z przyzwyczajenia jest dobrą rzeczą.

ifOświadczenie, moim zdaniem, w rzeczywistości obejmuje dwie odrębne funkcje.

Jeśli mamy coś zrobić, zrób to tutaj.

Takie rzeczy oczywiście nie wymagają elseczęści.

    if (customer.hasCataracts()) {
        appointmentSuggestions.add(new CataractAppointment(customer));
    }
    if (customer.isDiabetic()) {
        customer.assignNurse(DiabeticNurses.pickBestFor(customer));
    }

aw niektórych przypadkach naleganie na dodanie elsemoże wprowadzić w błąd.

    if (k > n) {
        return BigInteger.ZERO;
    }
    if (k <= 0 || k == n) {
        return BigInteger.ONE;
    }

to nie to samo co

    if (k > n) {
        return BigInteger.ZERO;
    } else {
        if (k <= 0 || k == n) {
            return BigInteger.ONE;
        }
    }

nawet jeśli jest funkcjonalnie taki sam. Pisanie pierwszego ifz pustym elsemoże doprowadzić do drugiego wyniku, który jest niepotrzebnie brzydki.

Jeśli sprawdzamy konkretny stan, często dobrym pomysłem jest dodanie pustego, elseaby przypomnieć o sytuacji

        // Count wins/losses.
        if (doors[firstChoice] == Prize.Car) {
            // We would have won without switching!
            winWhenNotSwitched += 1;
        } else {
            // We win if we switched to the car!
            if (doors[secondChoice] == Prize.Car) {
                // We picked right!
                winWhenSwitched += 1;
            } else {
                // Bad choice.
                lost += 1;
            }
        }

Pamiętaj, że te zasady obowiązują tylko podczas pisania nowego kodu . IMHO Puste elseklauzule powinny zostać usunięte przed odprawą.

Testuj true, a niefalse

Ponownie jest to dobra rada na poziomie ogólnym, ale w wielu przypadkach powoduje to, że kod jest niepotrzebnie złożony i mniej czytelny.

Mimo że kod podobny

    if(!customer.canBuyAlcohol()) {
        // ...
    }

denerwuje czytelnika, ale robi to

    if(customer.canBuyAlcohol()) {
        // Do nothing.
    } else {
        // ...
    }

jest co najmniej tak źle, jeśli nie gorzej.

I kodowane w BCPL wiele lat temu iw tym języku istnieje IFklauzula iUNLESS klauzula więc można kodować wiele bardziej czytelnie jako:

    unless(customer.canBuyAlcohol()) {
        // ...
    }

co jest znacznie lepsze, ale wciąż nie idealne.

Mój osobisty proces

Zasadniczo, gdy piszę nowy kod, często dodaję pusty elseblok do ifinstrukcji, aby przypomnieć mi, że nie opisałem jeszcze tej ewentualności. Pomaga mi to uniknąć DFSpułapki i zapewnia, że ​​kiedy przeglądam kod, zauważam, że jest więcej do zrobienia. Zazwyczaj jednak dodaję TODOkomentarz, aby śledzić.

  if (returnVal == JFileChooser.APPROVE_OPTION) {
    handleFileChosen();
  } else {
    // TODO: Handle case where they pressed Cancel.
  }

Uważam, że generalnie elserzadko używam w kodzie, ponieważ często może to wskazywać na zapach kodu.

Po pierwsze, użyłem języka, który wymusił użycie instrukcji IF w ten sposób (w Opal, język za skrobaczką do ekranu głównego do umieszczania interfejsu użytkownika GUI w systemach mainframe) i tylko z jedną linią dla IF i ELSE. To nie było przyjemne doświadczenie!

Spodziewałbym się, że każdy kompilator zoptymalizuje takie dodatkowe klauzule ELSE. Ale w przypadku kodu na żywo nic nie dodaje (w fazie rozwoju może być użytecznym znacznikiem dla dalszego kodu).

Czasem używam czegoś takiego jak te dodatkowe klauzule, kiedy używam przetwarzania typu CASE / WHEN. Zawsze dodam domyślną klauzulę, nawet jeśli jest pusta. Jest to długotrwały nawyk ze strony języków, które popełniają błąd, jeśli taka klauzula nie zostanie użyta, i zmusza do zastanowienia się, czy rzeczy naprawdę powinny po prostu przejść.

Dawno temu praktyka na komputerach mainframe (np. PL / 1 i COBOL) została przyjęta, że ​​kontrole negatywne były mniej skuteczne. To może wyjaśnić drugi punkt, chociaż w dzisiejszych czasach są znacznie ważniejsze oszczędności wydajności, które są ignorowane jako mikrooptymalizacje.

Negatywna logika bywa mniej czytelna, choć nie tak bardzo w przypadku tak prostej instrukcji IF.

Oparłbym stanowisko większości odpowiedzi, że puste elsebloki są praktycznie zawsze szkodliwym marnotrawstwem atramentu elektronicznego. Nie dodawaj ich, chyba że masz ku temu dobry powód, w którym to przypadku pusty blok wcale nie powinien być pusty, powinien zawierać komentarz wyjaśniający, dlaczego tak jest.

Problem unikania negatywów zasługuje jednak na większą uwagę: zazwyczaj, gdy trzeba użyć wartości logicznej, potrzebujesz bloków kodu do działania, gdy jest on ustawiony, oraz innych bloków do działania, gdy nie jest ustawiony. W związku z tym, jeśli wymusisz regułę nieujemną, wymuszasz albo posiadanie if() {} else {...}instrukcji (z pustym ifblokiem!), Albo tworzysz drugą wartość logiczną dla każdej wartości logicznej, która zawiera jej zanegowaną wartość. Obie opcje są złe, ponieważ dezorientują czytelników.

Pomocna zasada jest taka: Nigdy nie używaj zanegowanej formy w nazwie logicznej i wyrażaj negację jako pojedynczą !. Takie zdanie if(!doorLocked)jest całkowicie jasne, takie jak if(!doorUnlocked)mózg węzłów. Późniejszy rodzaj wyrażenia to rzecz, której należy unikać za wszelką cenę, a nie obecność jednego !w danym if()stanie.

Powiedziałbym, że to zdecydowanie zła praktyka. Dodanie innych instrukcji spowoduje dodanie do kodu całego szeregu bezcelowych wierszy, które nic nie robią, a jeszcze bardziej utrudnią ich odczytanie.

Jest jeszcze jeden wzorzec, który nie został jeszcze wspomniany na temat obsługi drugiego przypadku, który ma pusty blok if. Jednym ze sposobów radzenia sobie z tym jest powrót do bloku if. Lubię to:

void foo()
{
    if (condition) return;

    doStuff();
    ...
}

Jest to powszechny wzorzec sprawdzania warunków błędów. Przypadek twierdzący jest nadal używany, a jego wnętrze nie jest już puste, co pozwala przyszłym programistom zastanawiać się, czy rezygnacja nie była zamierzona. Może także poprawić czytelność, ponieważ może być konieczne utworzenie nowej funkcji (dzielenie dużych funkcji na mniejsze indywidualne funkcje).

Rozważając argument „zawsze mam inną klauzulę”, jest jeden punkt, którego nie widziałem w żadnej innej odpowiedzi: może mieć sens w funkcjonalnym stylu programowania. Raczej.

W funkcjonalnym stylu programowania operujesz wyrażeniami, a nie wyrażeniami. Zatem każdy blok kodu ma wartość zwracaną - w tym if-then-elsewyrażenie. Wykluczałoby to jednak pusty elseblok. Dam ci przykład:

var even = if (n % 2 == 0) {
  return "even";
} else {
  return "odd";
}

Teraz w językach ze składnią w stylu C lub inspirowaną stylem C (takich jak Java, C # i JavaScript, żeby wymienić tylko kilka), wygląda to dziwnie. Wygląda jednak znacznie lepiej, gdy jest napisany jako taki:

var even = (n % 2 == 0) ? "even" : "odd";

Pozostawienie elsetutaj pustej gałęzi spowodowałoby, że wartość byłaby niezdefiniowana - w większości przypadków nie jest to prawidłowy przypadek podczas programowania funkcji. To samo z całkowitym pominięciem. Jednak, gdy programujesz iteracyjnie, mam bardzo mało powodów, aby zawsze mieć elseblok.

... po instrukcji if powinna następować instrukcja else, niezależnie od tego, czy jest coś do wprowadzenia, czy nie.

Nie zgadzam się, że if (a) { } else { b(); }powinienem być przepisany jako if (!a) { b(); }i if (a) { b(); } else { }powinien zostać przepisany jako if (a) { b(); }.

Warto jednak zaznaczyć, że rzadko mam pustą gałąź. Jest tak, ponieważ normalnie loguję, że wszedłem do innej pustej gałęzi. W ten sposób mogę opracować wyłącznie komunikaty dziennika. Rzadko używam debugera. W środowiskach produkcyjnych nie ma debugera; miło jest móc rozwiązywać problemy produkcyjne za pomocą tych samych narzędzi, których używasz do programowania.

Po drugie, lepiej jest sprawdzić prawdziwe wartości niż fałsz. Oznacza to, że lepiej jest przetestować zmienną „doorClosed” zamiast zmiennej „! DoorOpened”

Mam mieszane uczucia na ten temat. Wadą posiadania doorClosedi doorOpenedpotencjalnie podwojenia liczby słów / terminów, o których musisz wiedzieć. Kolejną wadą jest z czasem znaczenie doorClosedi doorOpenedmoże się zmieniać (inni programiści przychodzą za tobą) i możesz skończyć z dwiema właściwościami, które nie są już dokładnymi zaprzeczeniami. Zamiast unikać negacji, cenię sobie dostosowanie języka kodu (nazw klas, nazw zmiennych itp.) Do słownictwa użytkowników biznesowych i do wymagań, które otrzymałem. Nie chciałbym wymyślać zupełnie nowego terminu, aby uniknąć!jeśli termin ten ma znaczenie tylko dla programisty, którego użytkownicy biznesowi nie zrozumieją. Chcę, aby programiści mówili tym samym językiem, co użytkownicy i osoby piszące wymagania. Teraz, jeśli nowe warunki upraszczają model, to ważne, ale należy się tym zająć przed sfinalizowaniem wymagań, a nie później. Projektanci powinni poradzić sobie z tym problemem, zanim zaczną kodować.

Jestem skłonny wątpić w mój instynkt.

Dobrze jest nadal zadawać sobie pytania.

Czy to dobra / zła / „nieważna” praktyka?

Do pewnego stopnia wiele z tego nie ma znaczenia. Sprawdź kod i dostosuj się do swojego zespołu. Zazwyczaj jest to właściwe. Jeśli wszyscy w twoim zespole chcą kodować w określony sposób, prawdopodobnie najlepiej to zrobić w ten sposób (zmiana 1 osoby - ciebie - zajmuje mniej punktów historii niż zmiana grupy ludzi).

Czy to powszechna praktyka?

Nie pamiętam, żeby widziałem pustą gałąź. Jednak widzę ludzi dodających właściwości, aby uniknąć negacji.

Zajmę się tylko drugą częścią pytania, a to wynika z mojego punktu widzenia pracy w systemach przemysłowych i manipulowania urządzeniami w prawdziwym świecie.

Jest to jednak w pewnym sensie rozszerzony komentarz, a nie odpowiedź.

Kiedy jest powiedziane

Po drugie, lepiej jest sprawdzić prawdziwe wartości niż fałsz. Oznacza to, że lepiej jest przetestować zmienną „doorClosed” zamiast zmiennej „! DoorOpened”

Jego argumentem jest to, że wyjaśnia on, co robi kod.

Z mojego punktu widzenia przyjmuje się tutaj założenie, że stan drzwi jest stanem binarnym, podczas gdy w rzeczywistości jest to przynajmniej stan potrójny:

1. Drzwi są otwarte.
2. Drzwi nie są całkowicie otwarte ani całkowicie zamknięte.
3. Drzwi są zamknięte.

Zatem w zależności od tego, gdzie znajduje się pojedynczy, binarny czujnik cyfrowy, można przypuszczać tylko jedną z dwóch koncepcji:

1. Jeśli czujnik znajduje się po otwartej stronie drzwi: drzwi są otwarte lub nie są otwarte
2. Jeśli czujnik znajduje się po zamkniętej stronie drzwi: drzwi są albo zamknięte, albo nie zamknięte.

I nie można wymieniać tych pojęć za pomocą binarnej negacji. Tak więc doorClosedi !doorOpenedprawdopodobnie nie są synonimami, a każda próba udawania, że ​​są synonimami, jest błędnym myśleniem, które zakłada większą wiedzę o stanie systemu niż w rzeczywistości istnieje.

Wracając do twojego pytania, poparłbym verbage, które pasuje do źródła informacji reprezentowanej przez zmienną. Tak więc, jeśli informacje pochodzą z zamkniętej strony drzwi, należy przejść z doorCloseditd. Może to oznaczać użycie jednego doorClosedlub !doorClosedw razie potrzeby w różnych oświadczeniach zgodnie z wymaganiami, co może spowodować potencjalne pomylenie z użyciem negacji. Ale to, czego nie robi, to pośrednio propaguje założenia dotyczące stanu systemu.

Do celów dyskusji na temat mojej pracy ilość dostępnych informacji o stanie systemu zależy od funkcjonalności wymaganej przez sam system.

Czasami muszę tylko wiedzieć, czy drzwi są zamknięte, czy nie zamknięte. W takim przypadku wystarczy pojedynczy czujnik binarny. Ale innym razem muszę wiedzieć, że drzwi są otwarte, zamknięte lub w trakcie przejścia. W takich przypadkach byłyby albo dwa czujniki binarne (na każdym krańcu ruchu drzwi - z kontrolą błędów przy jednoczesnym otwieraniu i zamykaniu drzwi) lub istniałby czujnik analogowy mierzący, jak „otwarte” były drzwi.

Przykładem pierwszego są drzwi do kuchenki mikrofalowej. Umożliwiają działanie piekarnika w zależności od tego, czy drzwiczki są zamknięte lub nie są zamknięte. Nie obchodzi cię, jak otwarte są drzwi.

Przykładem drugiego może być prosty siłownik napędzany silnikiem. Uniemożliwia się napędzanie silnika do przodu, gdy siłownik jest całkowicie wysunięty. I hamujesz napędzanie silnika do tyłu, gdy siłownik jest całkowicie włączony.

Zasadniczo liczba i rodzaj czujników sprowadza się do przeprowadzenia analizy kosztów czujników względem analizy wymagań dotyczących tego, co jest potrzebne do osiągnięcia wymaganej funkcjonalności.

Konkretne reguły stylu są zawsze złe. Wytyczne są dobre, ale w końcu często zdarza się, że możesz zrobić coś jaśniejszego, robiąc coś, co nie jest zgodne z wytycznymi.

To powiedziawszy, jest wiele nienawiści do pustych jeszcze „marnuje linie” „dodatkowego pisania”, które są po prostu złe. Możesz argumentować za przeniesieniem nawiasów na tę samą linię, jeśli naprawdę potrzebujesz przestrzeni pionowej, ale jeśli to jest problem, nie powinieneś umieszczać {w osobnej linii.

Jak wspomniano w innym miejscu, blok else jest bardzo przydatny, aby pokazać, że wyraźnie nie chcesz, aby nic się nie wydarzyło w innym przypadku. Po zrobieniu dużo programowania funkcjonalnego (gdzie jest to wymagane), nauczyłem się, że zawsze powinieneś brać pod uwagę inne przy pisaniu if, chociaż, jak wspomina @OldCurmudgeon, istnieją naprawdę dwa różne przypadki użycia. Trzeba mieć coś innego, nie należy. Niestety, nie jest to coś, co zawsze można powiedzieć na pierwszy rzut oka, nie mówiąc już o wkładce, stąd dogmatyczne „zawsze stawiaj inny blok”.

Jeśli chodzi o „brak negatywów”, ponownie, bezwzględne zasady są złe. Posiadanie pustego, jeśli może być dziwne, szczególnie jeśli jest to rodzaj, jeśli nie potrzebuje innego, więc pisz to wszystko, a nie! lub an == fałsz jest zły. To powiedziawszy, istnieje wiele przypadków, w których negatywne ma sens. Typowym przykładem może być buforowanie wartości:

static var cached = null

func getCached() {
    if !cached {
        cached = (some calculation, etc)
    }

    return cached
}

jeśli rzeczywista (mentalna / angielska) logika obejmuje negatywne, to samo powinno być w przypadku instrukcji if.