Lubię czysty kod, lubię ładny kod, lubię kod który mieści mi się na szerokości pół ekranu. Jestem wstanie wtedy nie tylko go przeczytać ale także śledzić. Jeśli jest on krótki to już w ogóle super sprawa. Jednak nie zawsze jest to możliwie i OK.
Jednak to co programiści najbardziej uwielbiają robić i robią to notorycznie to maksymalne zagnieżdżenia albo inaczej mówiąc zbędę zagnieżdżenia if na if’ie na if’e w pętli. Co nagle powoduje, że główna część metody znajduje się w odległości 6-8 tabów od początku metody. Powoduje to nie tylko to, że kod już nie mieści mi się na tak zwanej połówce ekranu, ale też mam kłopot z jego śledzeniem, który if został zamknięty? A ten 50 linijek wyżej i ten tutaj to otwiera if’a w 9 zagnieżdżeniu, ok. itp. Powiem tak MASAKRA. A już pomijając przypadki maksymalnego zagnieżdżenia – pętla w pętli z ifami na ifach :/ Ale zobaczmy prostszy przypadek, czy widzieliście lub sami napisaliście taki o to kod?
public object is_smth(string txt)
{
if(txt == "hello")
{
// Some custom long code, that expands on 50 lines of code with some other if's
}
return null; // throw new Exception ();
}
Ok, to teraz pytanie, dlaczego cały kod metody został wrzucony w tego if? Szczerze? Jesteście podać rozsądne wyjaśnienie dlaczego? Ja się nad tym nie raz zastanawiałem i nie jestem wstanie znaleźć żadnego uzasadnienia takiego if.
Czemu ten kod nie może wyglądać następująco:
public object is_smth(string txt)
{
if(txt != "hello")
{
return null; // throw new Exception ();
}
// Some custom long code, that expands on 50 lines of code with some other if's
}
Widzicie różnicę? Nie tylko z miejsca wiemy co się dzieje ale cały nasz kod nagle jest on poziom “wyżej” wcięciach. Przez co jest znacznie czytelniejszy i jesteśmy wstanie teraz mieć o “jeden” więcej poziomów zagłębienia, który może być wymagany.
Taki sposób myślenia i pisania kodu nazywa się fail fast – i polega on na tym, że głównym zadaniem jest znalezienie warunku który spowoduje zakończenie wykonywania się metody/kodu. Osobiście jestem jego wielkim zwolennikiem i robię to wszędzie gdzie się da. Także jeżeli mam kontakt z MASAKRĄ to odwracam jej warunki tylko po to by kod zaczął być czytelny.
Spróbujcie sami, zobaczycie jak bardzo wzrośnie czytelność waszego kodu.
Ja najczęściej taki kod widze jako pozostałość po (leniwym) sprzątaniu. TJ.
1) napisz dwa if’y
2) usuń drugi bo coś-tam, np. wymagania sie zmieniły
3) nie popatrz pare linijek wyżej że można metode uprościć no bo i po co
4) profit
W codziennym programowaniu resharper jest nieoceniony w wyłapywaniu takich pomyłek :)
@tchrikch
resharper pomaga, jak ktoś na niego zwraca uwagę :) Ja z takim kodem mam styczność bardzo często – czy to przykłady w sieci, czy po prostu kod napisany przez programistę który akurat miał taki tok myślenia (dosłownie spisany, jeżeli to jest równe to …). Ale tak, widzę też, że to ma prawo nie tylko być po leniwym sprzątaniu :) ale także po dodaniu nowej funkcjonalności – łatwiej coś opakować w if niż zmienić flow.
Zgadzam się, też mnie to wkurza.
Ale słyszałem kiedyś: Jedno wyjście z funkcji, bo inaczej to mamy GOTO
W środowisku C/C++ był kiedyś taki pogląd (w sumie ciekawe, czy nadal funkcjonuje)
Warto zaznaczyć, iż w niektórych przypadkach (wydajność) powinno się układać instrukcje warunkowe w kolejności od najczęsciej występującej do najrzadziej występującej.
Comments are closed.