Jaka jest różnica między stylami K&R a stylami One True Brace Style (1TBS)?

Przeczytałem artykuł w Wikipedii na temat Stylów wcięć , ale nadal nie rozumiem. Jaka jest różnica między K&R a 1TBS?

Największą różnicą między K & R i Jedynego Prawdziwego Podpora Style (1TBS) jest to, że w 1TBS, wszystko if, else, while, i foroświadczenia mają szelki otwarcia i zamknięcia, nawet jeśli nie są konieczne. Celem jest ułatwienie wstawiania nowych instrukcji i dokładna znajomość ich grupowania.

Jako przykład:

K&R:

int i;
for (i = 0; i < 10; i++)
  printf("Hi.");

1 TB:

int i;
for (i = 0; i < 10; i++) {
  printf("Hi");
}

K&R wygląda tak:

if (x) 
    a();
else {
    b();
    c();
}

To znaczy: nawiasy klamrowe używane tylko w razie potrzeby, otwieranie nawiasu klamrowego w tym samym wierszu co instrukcja sterująca, zamykanie nawiasu klamrowego we własnej linii.

„Jeden prawdziwy styl nawiasów klamrowych” (1TBS lub OTBS) zmienia pojedynczą instrukcję sterowaną w instrukcję złożoną, umieszczając ją w nawiasach klamrowych:

if (x) {
    a();
} else {
    b();
    c();
}

Styl Allmana idzie nieco dalej niż 1 TB i wymusza pionowe odstępy, umieszczając również nawias otwierający na linii:

if (x) 
{
    a();
}
else 
{
    b();
    c();
}

Edytować:

Wciąż próbuję dowiedzieć się, jak to się kwalifikuje jako „arogancki”, mówiąc: „Dennis Ritchie był wyjątkowo mądrym facetem, który nie tylko wynalazł dobry język, ale także wymyślił naprawdę dobry styl ortezy”.

Dla tych, którzy twierdzą, że i tak jest arogancki, oto małe wyzwanie: przejdź do Sourceforge, Github (itp.) I wybierz projekty w stylu klamrowym K&R. Przejrzyj ich zapisy błędów i zatwierdzeń i spróbuj znaleźć pojedynczy błąd, który został spowodowany przez używany przez nich styl nawiasów klamrowych.

Jeśli nie chcesz wykonywać tak dużo pracy, spróbuj wykonać prostą analizę statystyczną. Porównaj projekty przy użyciu różnych stylów stężeń i sprawdź, czy możesz pokazać „bimodalność” - statystycznie istotną różnicę w liczbie błędów (dotkliwość itp.), Która koreluje ze stylem stężeń.

Zrobiłem to kilka lat temu i nie mogłem znaleźć ani jednego błędu, który mógłbym przypisać stylom wzmacniającym, ani nie mogłem znaleźć niczego zbliżającego się do statystycznie istotnej korelacji między nimi. Średnio osoby używające stężenia K&R miały nieco mniej błędów, ale różnica była zdecydowanie zbyt mała, aby można ją było uznać za statystycznie znaczącą.

Odkąd został przywołany, skomentuję sytuację za pomocą makr z wieloma instrukcjami. Makro, które zawiera wiele instrukcji, ale nie otacza ich nawiasami klamrowymi, zawiera błąd. Moim zadaniem nie jest pisanie kodu, który ukrywałby ten błąd. Wręcz przeciwnie, moim zadaniem jest jak najszybsze znalezienie i wyeliminowanie tego błędu.

Pisanie kodu w nadziei na zatuszowanie błędów, aby pozostały nierozpoznane i nierozwiązane, jest po prostu złem. Nazwij to aroganckim, jeśli chcesz, ale nie uważam tego za nawet blisko do negocjacji. Błędy należy znaleźć i naprawić, a nie ukryć. Im dłużej istnieją, tym bardziej prawdopodobne jest, że będą one trudniejsze i droższe do naprawienia.

Problemem ogólnie w stylu nawiasów klamrowych jest refaktoryzacja kodu. Podczas przenoszenia kodu łatwo jest przeoczyć, że nie ma wokół niego nawiasów klamrowych, przesuń go nieprawidłowo (lub przesuń coś pod nim, myśląc, że jest to warunkowo wykonane), a następnie albo podrap się po głowie, gdy coś już nie działa, albo bądź niefortunny i bądź w tym obszar kodu nie został dobrze przetestowany, a błąd pozostaje niezauważony, dopóki czarny kapelusz nie znajdzie sposobu na jego wykorzystanie. Szybka podróż do debugera z łatwością znajdzie problem, jeśli go zauważysz, ale jeśli nie ...