Здебільшого це особисті переваги, проте слід враховувати деякі речі.
Можливі помилки
Хоча можна стверджувати , що помилки , викликані забуваючи додати в фігурних дужках зустрічаються рідко, від того, що я бачив , що вони дійсно трапляються час від часу (не забути відомий IOS Гото невдачі помилки). Тому я думаю, що це має бути фактором при розгляді вашого стилю коду (деякі інструменти попереджають про введення в оману відступів , тому це також залежить від вашої ланцюжка інструментів) .
Дійсний код (він говорить про те, що це може бути помилка)
Навіть якщо припустити, що ваш проект не страждає від таких помилок, при читанні коду ви можете побачити деякі блоки коду, схожі на те, що вони можуть бути помилками, але ні, не беручи до уваги певний розумовий цикл.
Почнемо з:
if (foo)
bar();
Розробник додає корисний коментар.
if (foo)
// At this point we know foo is valid.
bar();
Пізніше розробник розширює його.
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();
Або додає вкладений блок:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Або використовує макрос:
if (foo)
SOME_MACRO();
"... Оскільки макроси можуть визначати кілька рядків коду, чи використовує макрос do {...} while (0)для декількох рядків? Це повинно бути, тому що це в нашому посібнику зі стилів, але я краще перевіряю про всяк випадок!"
Наведені вище приклади - це дійсний код, однак чим більше вмісту в кодовому блоці, тим більше вам потрібно прочитати, щоб упевнитись у помилках.
Можливо, ваш стиль коду визначає, що для багаторядкових блоків потрібна дужка (незважаючи ні на що, навіть якщо вони не є кодом) , але я бачив, що такі коментарі додаються у виробничий код. Коли ви читаєте його, виникає невеликий сумнів, що той, хто востаннє редагував ці рядки, забув додати дужку, іноді я відчуваю необхідність повторної перевірки, працює за призначенням (особливо при дослідженні помилки в цій області коду) .
Різний шум
Однією практичною причиною використання дужок для одиночних ліній є зменшення різного шуму .
Тобто, змінюючи:
if (foo)
bar();
До:
if (foo) {
bar();
baz();
}
... спричиняє появу умовної лінії в різниці як зміну, це додає невеликі, але непотрібні накладні витрати.
- рядки відображаються як змінені в оглядах коду, якщо ваші різні інструменти на основі слів, ви можете легко побачити, що змінилася лише дужка, але для того, щоб перевірити, чи не змінилася лінія взагалі, потрібно більше часу.
Сказавши, що не всі інструменти підтримують слово, що базується на розрізненні, diff (svn, git, hg ... і т. Д.), Покаже, ніби весь рядок змінився, навіть із вигадливими інструментами, іноді вам може знадобитися швидко переглянути звичайний рядок -оснований Dif, щоб побачити, що змінилося.
- інструменти для анотацій (такі як
git blame) показуватимуть рядок як змінений, зробивши відстеження походження рядка ще кроком до пошуку реальних змін.
Вони обидві і невеликі, і залежать від того, скільки часу ви витрачаєте на перегляд коду чи відстеження, які здійснюють змінені рядки коду.
Більш відчутна незручність в тому, щоб додаткові зміни рядків були різними, їхня велика ймовірність, що зміни в коді призведуть до конфліктів, які об'єднуються та їх потрібно вирішити вручну .
Є виняток із цього, для баз кодів, які мають {свій рядок - це не проблема.
Аргумент різного шуму не дотримується, якщо ви пишете в цьому стилі:
if (foo)
{
bar();
baz();
}
Однак це не така поширена конвенція, тому головним чином додається відповідь на повноту (не пропонуючи проекти використовувати цей стиль) .
