W przeważającej części jest to osobiste preferencje, jednak należy rozważyć kilka kwestii.
Możliwe błędy
Chociaż można argumentować, że błędy spowodowane przez zapomnienie o dodaniu nawiasów klamrowych są rzadkie, z tego, co widziałem , że zdarzają się od czasu do czasu (nie zapominając o słynnym błędzie IOS goto fail ). Myślę więc, że powinien to być czynnik przy rozważaniu twojego stylu kodu (niektóre narzędzia ostrzegają przed wprowadzającymi w błąd wcięciami , więc zależy to również od łańcucha narzędzi) .
Poprawny kod (który czyta się jak to może być błąd)
Nawet zakładając, że twój projekt nie cierpi z powodu takich błędów, podczas czytania kodu możesz zobaczyć pewne bloki kodu, które wyglądają, jakby mogły być błędami - ale nie biorą udziału w twoich cyklach mentalnych.
Zaczynamy od:
if (foo)
bar();
Deweloper dodaje przydatny komentarz.
if (foo)
// At this point we know foo is valid.
bar();
Później programista rozwija się na nim.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
Lub dodaje zagnieżdżony blok:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Lub używa makra:
if (foo)
SOME_MACRO();
„... Ponieważ makra mogą definiować wiele linii kodu, czy makro używa do {...} while (0)wielu linii? Powinno tak być, ponieważ jest w naszym przewodniku po stylu, ale lepiej na wszelki wypadek to sprawdzić!”
Powyższe przykłady są poprawnymi kodami, jednak im więcej treści w bloku kodu, tym więcej trzeba przeczytać, aby upewnić się, że nie ma żadnych błędów.
Być może twój styl kodu określa, że bloki wieloliniowe wymagają nawiasów klamrowych (bez względu na wszystko, nawet jeśli nie są kodem) , ale widziałem tego rodzaju komentarze dodawane w kodzie produkcyjnym. Kiedy ją czytasz, istnieje niewielka wątpliwość, że ktokolwiek ostatnio edytował te wiersze, zapomniał dodać nawias klamrowy, czasami czuję, że potrzeba podwójnego sprawdzenia działa zgodnie z przeznaczeniem (szczególnie podczas badania błędu w tym obszarze kodu) .
Zróżnicowany hałas
Jednym praktycznym powodem stosowania aparatów ortodontycznych do pojedynczych linii jest redukcja szumów różnicowych .
Oznacza to zmianę:
if (foo)
bar();
Do:
if (foo) {
bar();
baz();
}
... powoduje, że linia warunkowa wyświetla się w różnicy, gdy jest zmieniana, co powoduje pewne małe, ale niepotrzebne obciążenie.
- wiersze pokazują się jako zmienione w recenzjach kodu, jeśli twoje narzędzia różnicowania są oparte na słowach, możesz łatwo zobaczyć, że zmienił się tylko nawias klamrowy, ale sprawdzenie to zajmuje więcej czasu, a następnie, czy wiersz w ogóle się nie zmienił.
Powiedziawszy to, nie wszystkie narzędzia obsługują diffing oparty na słowach, diff (svn, git, hg ... itp.) Pokaże, jakby cała linia uległa zmianie, nawet przy użyciu fantazyjnych narzędzi, czasami może być konieczne szybkie spojrzenie po prostej linii na podstawie różnic, aby zobaczyć, co się zmieniło.
- narzędzia do adnotacji (takie jak
git blame) pokażą linię jako zmienioną, dzięki czemu śledzenie początku linii będzie krokiem do znalezienia prawdziwej zmiany.
Są one zarówno niewielkie, jak i zależą od tego, ile czasu spędzasz na przeglądaniu lub śledzeniu kodu, które zatwierdzają zmienione wiersze kodu.
Bardziej namacalną niedogodnością związaną z wprowadzaniem zmian w dodatkowych wierszach w różnicach, jest większe prawdopodobieństwo, że zmiany w kodzie spowodują scalenie konfliktów i należy je rozwiązać ręcznie .
Istnieje wyjątek od tego, w przypadku baz kodu, które mają {własną linię - to nie jest problem.
Hałas diff argument nie trzymać jeśli piszesz w tym stylu:
if (foo)
{
bar();
baz();
}
Jednak nie jest to tak powszechna konwencja, więc głównie dodaje się do odpowiedzi na kompletność (nie sugerując, że projekty powinny używać tego stylu) .
