По большей части это личные предпочтения, однако есть некоторые вещи, которые следует учитывать.
Возможные ошибки
Хотя можно утверждать , что ошибки , вызванные забывая добавить в фигурных скобках встречаются редко, от того, что я видел , что они действительно случаются время от времени (не забыть известный 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 как измененную, это добавляет небольшие, но ненужные накладные расходы.
- линии отображаются как измененные в обзорах кода, если ваши инструменты сравнения основаны на словах, вы можете легко увидеть, что изменилась только фигурная скобка, но требуется больше времени, чтобы проверить, изменилась ли строка вообще.
Тем не менее, не все инструменты поддерживают дифференцирование на основе слов, diff (svn, git, hg ... и т. Д.) Будет отображаться так, как будто вся строка изменилась, даже с помощью необычных инструментов, иногда вам может понадобиться быстро просмотреть простую линию на основе различий, чтобы увидеть, что изменилось.
- Инструменты аннотации (например,
git blame) покажут линию как измененную, делая отслеживание происхождения линии еще одним шагом, чтобы найти реальное изменение.
Они оба малы и зависят от того, сколько времени вы тратите на проверку кода или отслеживание изменений, которые фиксируют измененные строки кода.
Более ощутимое неудобство, связанное с наличием дополнительных различий строк в diff, их более высокая вероятность изменений в коде вызовет конфликты, которые сливаются и должны быть разрешены вручную .
Есть исключение из этого, для кодовых баз, которые имеют {свою собственную строку - это не проблема.
Дифф шум аргумент не имеет места , если вы пишете в этом стиле:
if (foo)
{
bar();
baz();
}
Однако это не такое распространенное соглашение, поэтому в основном добавление к ответу для полноты (не предлагая проектам использовать этот стиль) .
