Я ненавижу ссылаться на контент Paywalled, но это видео показывает именно то, о чем я говорю. Точно 12 минут Роберта Мартина выглядит так:

И говорит: «Одна из моих любимых вещей - избавиться от бесполезных скобок», когда он превращает это в это:

Давным-давно, в далеком образовании меня учили не делать этого, потому что это позволяет легко ввести ошибку, добавив еще одну строку с отступом, думая, что она контролируется, ifкогда это не так.

Честно говоря, дядя Боб реорганизует длинный Java-метод, превращая его в крошечные маленькие функции, которые, я согласен, гораздо более читабельны. Когда он закончил изменять его, (22.18) это выглядит так:

Мне интересно, если это должно подтвердить удаление скобок. Я уже знаком с лучшей практикой . Может ли дядя Боб быть оспорен в этом вопросе? Дядя Боб защищал идею?

Читаемость не маленькая вещь.

Я смешанный, когда дело доходит до скобок, которые заключают в себе один метод. Я лично удаляю их для таких вещей, как однострочные операторы возврата, но отсутствие таких скобок на самом деле очень сильно укусило нас в последнем месте, где я работал. Кто-то добавил строчку кода в ifоператор, не добавив также необходимые фигурные скобки, и, поскольку это был C, он без предупреждения вывел систему из строя.

Я никогда не бросаю вызов никому, кто религиозен в том, чтобы всегда использовать фигурные скобки после этого маленького фиаско.

Таким образом, я вижу преимущество читабельности, но я четко осознаю проблемы, которые могут возникнуть, когда вы оставите эти скобки.

Я не стал бы пытаться найти исследование или чье-то опубликованное мнение. У каждого есть один (мнение, то есть), и поскольку это стилистическая проблема, одно мнение примерно так же хорошо, как и любое другое. Подумайте о проблеме самостоятельно, оцените все «за» и «против» и решите сами. Если в магазине, в котором вы работаете, есть стандарт кодирования, охватывающий эту проблему, просто следуйте этому.

Вы можете найти несколько опубликованных промо-акций или отклонений стилей без скобок здесь или здесь, или там, где нарисованы навесы для велосипедов.

Отойдя от велосипедных сараев, помните отличную ошибку OS X / iOS SSL 2014 года?

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

Да, "вызвано" блоками без скобок https://www.imperialviolet.org/2014/02/22/applebug.html

Предпочтения могут зависеть от стиля скобки. Если бы мне пришлось написать

if (suiteSetup)
{
    includePage(mode, suiteSetup);
}

Я мог бы быть склонен к экономии места тоже. Но

if (suiteSetup) {
    includePage(mode, suiteSetup);
}

использует только одну «лишнюю» строку.

Я знаю, что ты не спрашивал, но если я работаю один, я еретик. Если я снимаю брекеты, я предпочитаю

if (suiteSetup != null) includePage(mode, suiteSetup);

Он не имеет той же визуальной проблемы, что и ошибка в стиле SSL в iOS, но сохраняет еще больше «ненужных» строк, чем это делает дядя Боб;) Хорошо читает, если вы к этому привыкли, и широко используется в Ruby ( includePage(mode, suiteSetup) unless suiteSetup.nil?). Ну да ладно, просто знай, что мнений много.

У дяди Боба есть много уровней защиты от такой ошибки, которая не была настолько распространенной, когда «всегда использовать фигурные скобки» было преобладающей мудростью:

1. Сильное личное предпочтение однострочных условных выражений, поэтому многострочные условно выделяются и подвергаются дополнительной проверке.
2. Редактор, который автоматически выделяется при вставке второй строки.
3. Полный набор юнит-тестов, которые он запускает постоянно.
4. Полный набор интеграционных тестов.
5. Рецензирование сделано до слияния его кода.
6. Перезапуск всех тестов сервером непрерывной интеграции.
7. Тестирование выполнено отделом качества продукции.

Я думаю, что если кто-то опубликует вызов дяде Бобу, у него будет довольно хорошее опровержение с указанными выше пунктами. Это одна из самых простых ошибок, чтобы поймать рано.

По большей части это личные предпочтения, однако есть некоторые вещи, которые следует учитывать.

Возможные ошибки

Хотя можно утверждать , что ошибки , вызванные забывая добавить в фигурных скобках встречаются редко, от того, что я видел , что они действительно случаются время от времени (не забыть известный 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();
}

Однако это не такое распространенное соглашение, поэтому в основном добавление к ответу для полноты (не предлагая проектам использовать этот стиль) .

Несколько лет назад меня привели для отладки кода на Си. Ошибка была безумно трудна для поиска, но в конечном итоге она сводилась к следующему утверждению:

if (debug)
   foo (4);

И оказалось, что человек, который написал это, определил fooкак макрос. Макрос с двумя строками кода. И, конечно, только первая из этих двух строк была предметом if. (Таким образом, вторая строка была выполнена безоговорочно.)

Это может быть абсолютно уникальным для C и его препроцессора, который выполняет подстановки перед компиляцией, но я никогда не забывал об этом. Подобные вещи накладывают отпечаток на вас, и почему бы не проигнорировать их, особенно если вы используете различные языки и наборы инструментов и не можете быть уверены, что такие махинации невозможны в других местах?

Теперь я делаю отступы и использую фигурные скобки не так, как все остальные. Для одной строки ifя бы сделал:

if (debug) { foo (4); }

поэтому не требуется никаких дополнительных строк для включения скобок.

«Дяде Бобу» разрешено иметь свое мнение, вам разрешено иметь свое мнение. Не нужно бросать ему вызов.

Если вы хотите обратиться к власти, возьмите Криса Латтнера. В Swift, если операторы потеряли свои скобки, но всегда идут с фигурными скобками. Без обсуждения, это часть языка. Так что, если «Дядя Боб» начинает удалять фигурные скобки, код перестает компилироваться.

Просматривать чужой код и «избавляться от бесполезных скобок» - плохая привычка. Только вызывает дополнительную работу, когда код должен быть проверен, и когда ненужные конфликты создаются. Может быть, «Дядя Боб» такой невероятно хороший программист, что ему не нужны обзоры кода? Я потратил впустую одну неделю своей жизни, потому что один главный программист изменил «if (p! = NULL)» на «if (! P)» без проверки кода, скрытого в худшем из возможных мест.

Это в основном безобидный стиль дебатов. Преимущество скобок заключается в том, что вы можете вставить еще одну строку кода без добавления скобок. Как заявление о регистрации или комментарий (если за ним следует комментарий, за которым следует утверждение, просто ужасно). Заявление в той же строке, как будто имеет практический недостаток, что у вас проблемы со многими отладчиками. Но делай что хочешь.

Мои причины не снимать брекеты:

1. уменьшить усталость решения. Если вы всегда используете брекеты, вам никогда не придется решать, нужны ли вам брекеты или нет.

2. уменьшить перетаскивание разработки: даже если вы стремитесь в конечном итоге извлечь все несколько строк логики в методы, необходимость преобразовывать фигурную скобку, если в фигурную скобку, если добавить логику, раздражает. Таким образом, мы пытаемся удалить фигурные скобки и добавить их снова, когда вам нужно больше кода. Крошечный, но раздражающий.

Молодой сотрудник сказал, что брекеты, которые мы считаем излишними и излишними, на самом деле полезны для него. Я не помню точно, почему, но если это позволяет ему быстрее писать более качественный код, это одна из причин, по которой стоит их сохранить.

FWIW, мы согласились на компромиссе , что ставит их на одной линии не делает такие короткие предпосылки ООН читаемыми / отвлекая мне. Например

if (!param) { throw invalid_argument (blahblah); }
if (n < 2) { return 0; }
// real code for function starts here...

Я также отмечаю, что эти вводные предварительные условия часто являются операторами потока управления для тела (например, а return), поэтому боязнь добавить второе утверждение, которое должно быть в том же условии, и забыть написать фигурные скобки, является спорным. Второе утверждение при условии будет в любом случае мертвым кодом и не имеет смысла.

Я подозреваю, что беглость в чтении вызвана тем, что анализатор мозга человека подключен к фигурным скобкам как часть условного утверждения. Это не точное представление грамматики C ++, но может быть побочным эффектом изучения некоторых других языков в первую очередь, где это имеет место.

Посмотрев это видео только сейчас, я заметил, что устранение скобок облегчает понимание того, где еще нужно выполнить рефакторинг кода. Если вам нужны фигурные скобки, ваш код может быть немного чище.

Сказав это, когда вы в команде, удаление скобок, вероятно, приведет к неожиданному поведению когда-нибудь. Я говорю: оставь их, и ты избавишь себя от множества головных болей, когда что-то пойдет не так.

Меня учили не делать этого, потому что это позволяет легко ввести ошибку, добавив еще одну строку с отступом, думая, что она контролируется if, если это не так.

Если ваш код хорошо протестирован модулем , этот «баг» взорвется прямо в лицо.

Очистить код, избегая ненужных и безобразных скобок, - это практика, которой я следую.