Яка різниця між стилями K&R та One True Brace Style (1TBS)?

Я прочитав статтю Вікіпедії про стилі відступу , але все ще не розумію. Яка різниця між K&R та 1TBS?

Найбільша різниця між K & R і Єдиним Справжнім Brace Style (1TBS) є те , що в 1TBS, все if, else, whileі forзатвердження має відкриття і закриття дужки, навіть якщо вони не потрібні. Мета - спростити вставлення нових висловлювань і точно знати, як вони будуть групуватися.

Як приклад:

K&R:

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

1TBS:

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

K&R виглядає так:

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

Тобто: дужки, які використовуються лише там, де це потрібно, відкриття дужки на тій же лінії, що і контрольна заява, закриття дужки на власній лінії.

"Один істинний стиль дужки" (1TBS або OTBS) перетворює єдине кероване твердження в складене твердження, додаючи його в дужки:

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

Стиль Allman йде трохи далі, ніж 1TBS, і змушує вертикальний інтервал, розміщуючи також відкриваючу дужку на лінії:

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

Редагувати:

Я все ще намагаюся розібратися, як саме це кваліфікується як "зарозумілий", щоб сказати: "Денніс Річі був надзвичайно розумним хлопцем, який не тільки вигадав добру мову, але і придумав дійсно гарний брекет-стиль".

Для тих, хто наполягає на тому, що це все одно викликає зарозумілість, ось вам невеличкий виклик: перейдіть до Sourceforge, Github (тощо) та виберіть проекти, використовуючи брекет-стиль K&R. Перегляньте свої записи про помилки та комунікації та спробуйте знайти єдину помилку, яка була викликана стилем дужки, який вони використовували.

Якщо ви не хочете займатися такою великою роботою, спробуйте зробити простий статистичний аналіз. Порівняйте проекти, використовуючи різні стилі брекетів, і подивіться, чи можна проявити "бімодальність" - статистично значуща різниця в кількості помилок (ступінь вираженості тощо), яка співвідноситься зі стилем обведення.

Я робив це обидва кілька років тому, і не зміг знайти жодної помилки, яку я міг би віднести до стилів, що зміщують, і я не міг знайти нічого, що наближалося б до статистично значущої кореляції між ними. В середньому, ті , які використовують K & R розпірка була трохи менше помилок, але різниця була набагато занадто малий , щоб кваліфікувати в якості статистично значущою.

Оскільки він був висунутий, я прокоментую ситуацію з макросами з кількома заявами. Макрос, який включає кілька операторів, але не оточує їх самими дужками, має помилку. Моя робота - не писати код, який приховує цю помилку. Зовсім навпаки, моя робота - знайти та усунути цю помилку якомога швидше.

Написання коду в надії його приховати помилки, щоб вони залишалися недіагностованими та не виправленими - це прямо зло. Якщо ви хочете, зателефонуйте цьому зарозумілому, але я не вважаю це навіть близьким до домовленості. Помилки слід знайти та виправити, а не прикривати. Чим довше існують, тим більше шансів на те, що вони стануть набагато складнішими та дорогими для виправлення.

Проблема, як правило, у стилі брекетів KR полягає в рефакторингу коду. Під час переміщення коду легко не помітити, що навколо чогось немає дужок, перенесіть його неправильно (або перемістіть щось під ним, думаючи, що це умовно виконується), а потім або почухайте голову, коли щось більше не працює, або невдало і опинитися в область коду недостатньо перевірена і помилка залишається непоміченою, поки чорна шапка не знайде способу її використовувати. Швидка поїздка до налагоджувача легко знаходить проблему, якщо ви її помітили, але якщо ви цього не зробите ...