Обязательное использование фигурных скобок

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

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

Тем не менее, мне нравятся однострочные возвраты и продолжение, предложенные Гасом. Цель очевидна, она понятна и легче читается.

Вау. НИКТО не знает о проблеме зависшего другого ? Это, по сути, причина всегда использовать фигурные скобки.

Короче говоря, у вас может быть неприятная неоднозначная логика с операторами else, особенно когда они вложены. Разные компиляторы разрешают неоднозначность по-своему. Отказ от скобок может стать огромной проблемой, если вы не знаете, что делаете.

Эстетика и удобочитаемость не имеют никакого отношения к этому.

Here are the unwritten (until now I suppose) rules I go by. I believe it provides readability without sacrificing correctness. It's based on a belief that the short form is in quite a few cases more readable than the long form.

• Always use braces if any block of the if/else if/else statement has more than one line. Comments count, which means a comment anywhere in the conditional means all sections of the conditional get braces.
• Optionally use braces when all blocks of the statement are exactly one line.
• Never place the conditional statement on the same line as the condition. The line after the if statement is always conditionally executed.

• If the conditional statement itself performs the necessary action, the form will be:

  for (init; term; totalCount++)
  {
   // Умышленно оставлено пустым
  }
  

Нет необходимости стандартизировать это подробным образом, если вы можете просто сказать следующее:

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

Я не верю вашим аргументам. Лично я не знаю никого, кто бы «случайно» добавил вторую строку под if . Я бы понял, если бы сказал, что вложенные операторы if должны иметь фигурные скобки, чтобы избежать зависания else, но, как я вижу, вы применяете стиль из-за опасений, что, ИМО, это неуместно.

Еще одно преимущество постоянного использования фигурных скобок состоит в том, что они упрощают автоматические операции поиска и замены и аналогичные операции.

Например: Предположим, я заметил, что обычно используется functionB вызывается сразу после functionA с аналогичным шаблоном аргументов, поэтому я хочу преобразовать этот дублированный код в новую комбинированную_функцию . Регулярное выражение может легко справиться с этим рефакторингом, если у вас нет достаточно мощного инструмента рефакторинга ( ^ \ s + functionA. *?; \ N \ s + functionB. * ?; ), но без фигурных скобок простой подход с использованием регулярных выражений может потерпеть неудачу:

if (x)
  functionA(x);
else
  functionA(y);
functionB();

станет

if (x)
  functionA(x);
else
  combined_function(y);

Более сложные регулярные выражения будут работать в этом конкретном случае, но я нашел очень удобным иметь возможность использовать поиск и замену на основе регулярных выражений, одноразовые Сценарии Perl и аналогичное автоматическое обслуживание кода,

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

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

Примеры, которые вы приводите, действительны, но у них есть лучшие решения, чем принуждение скобок:

Когда вы не делаете ' t заключите в скобки одну строку, а затем кто-то закомментирует это, у вас проблемы.

Две практики решают эту проблему лучше, выберите один:

1) Закомментируйте if , , а и т.д. перед однострочным с однострочным. Т.е. относитесь к

if(foo)
    bar();

как к любому другому многострочному оператору (например, к назначению с несколькими строками или к вызову функции с несколькими строками):

//if(foo)
//    bar();

2) Префикс // с ; :

if(foo)
;//    bar();

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

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

Напишите код Python. Это исправит, по крайней мере, некоторые плохие привычки отступов.

Кроме того, такие структуры, как } else {, для меня выглядят как nethack-версию TIE-истребителя.

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

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

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

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

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

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

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

I '

Многие языки имеют синтаксис для однострочников, подобных этому (я имею в виду, в частности, Perl), чтобы справиться с таким "уродством". Так что что-то вроде:

if (foo)     
//bar
else     
//baz

может быть записано как тернарное с использованием тернарного оператора:

foo ? bar : baz

и

while (something is true)
{
blah 
}

могут быть записаны как:

blah while(something is true)

Однако в языках, в которых нет этого «сахара», я бы определенно включил подтяжки. Как вы сказали, он предотвращает появление ненужных ошибок и проясняет намерения программиста.

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

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

Итак, чтобы создать стандарт кодирования:

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

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

• Расставьте приоритеты в правилах по их измеримому влиянию на качество кода. Сколько ошибок вы можете избежать, применяя правило (например, «всегда проверять на null», «всегда проверять параметры с помощью утверждения», «всегда писать модульный тест» по сравнению с «всегда добавлять фигурные скобки, даже если они не нужны») . Предыдущие правила спасут вас от тысяч ошибок в год. Правило скобок может спасти вас. Может быть.

• Соблюдайте самые эффективные правила и отбросьте плевелы. Чушь - это, как минимум, любое правило, реализация которого будет стоить вам больше, чем любые ошибки, которые могут возникнуть при игнорировании правила. Но, вероятно, если у вас более 30 ключевых правил, ваши программисты проигнорируют многие из них, и ваши добрые намерения будут как прах.

• Увольте любого программиста, который комментирует случайные фрагменты кода, не читая его: -)

PS Моя позиция в отношении фиксации такова: если оператор «if» или его содержание являются обе в одну строку, то фигурные скобки можно опустить. Это означает, что если у вас есть if, содержащий однострочный комментарий и одну строку кода, содержимое занимает две строки, и поэтому необходимы фигурные скобки. Если условие if охватывает две строки (даже если содержимое является одной строкой), вам нужны фигурные скобки. Это означает, что вы опускаете фигурные скобки только в тривиальных, простых и легко читаемых случаях, когда на практике никогда не допускаются ошибки. (Когда оператор пуст, я не использую фигурные скобки, но я всегда помещаю комментарий, четко указывающий, что он пуст, и намеренно так. Но это граничит с другой темой:

В зависимости от языка наличие фигурных скобок для однострочного условного оператора или оператора цикла не является обязательным. Фактически, я бы удалил их, чтобы было меньше строк кода.

C ++:

Версия 1:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

Версия 2:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C #:

Версия 1:

foreach(string s in myList)
   Console.WriteLine(s);

Версия2:

foreach(string s in myList)
{
   Console.WriteLine(s);
}

В зависимости от вашей точки зрения, версия 1 или версия 2 будет более читабельной. Ответ скорее субъективный .

Для подобных вещей я бы рекомендовал просто придумать шаблон конфигурации для автоформатора вашей IDE. Затем, когда ваши пользователи нажимают alt-shift-F (или любое другое нажатие клавиши в выбранной вами IDE), фигурные скобки будут добавлены автоматически. Затем просто скажите всем: «Идите и измените цвет шрифта, настройки PMD или что-то еще. Однако, пожалуйста, не меняйте правила отступов или автоматических скобок».

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

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

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

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

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

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

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

Я также не могу предложить лучшего контраргумента. Сожалею! ;)

Мое личное правило: если это очень короткое "если", то помещайте все это в одну строку:

if(!something) doSomethingElse();

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

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

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

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

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

Преимущества намного превосходят любую «кажется некрасивой» причину, которую я слышал.

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

Это тот стандарт, который действительно окупается.