Обязательное использование брекетов

Question

В рамках документа стандартов кода, который я написал некоторое время назад, я применяю «вы всегда должны использовать брекеты для петли и/или условных блоков кода, даже (особенно), если они только одна строка».

Пример:

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

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

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

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

Answer 1

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

Итак, это правильно по моему стандарту:

if(true) continue;

Как это

if(true) return;

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

if(foo)
    bar();

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

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

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

if(foo)
;//    bar();

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

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

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

Кроме того, такие структуры, как } else { Для меня выглядит как версия борца за галстук.

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

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

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

Принуждение брекетов не помогает найти ошибку в приведенном выше коде.

PS Я абонент «Каждое правило должно сказать, почему», или, как сказал Далай -лама: «Знай правила, чтобы вы могли правильно их нарушить».

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

while (things) 
{
    // stuff
}

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

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

Answer 7

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

Answer 8

Мое личное правило заключается в том, что это очень короткое «если», то поместите все на одну строку:

if(!something) doSomethingElse();

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

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

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

Answer 9

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

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

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

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

Answer 10

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

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

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

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

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

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

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

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

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

Answer 11

Многие языки имеют синтаксис для одного такого лайнера (в частности, я думаю о Perl), чтобы справиться с таким «безобразием». Итак, что -то вроде:

if (foo)     
//bar
else     
//baz

может быть написан как тройной, используя тройной оператор:

foo ? bar : baz

а также

while (something is true)
{
blah 
}

может быть написано как:

blah while(something is true)

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

Answer 12

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

Answer 13

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

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

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

станет

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

В этом конкретном случае более сложные режимы будут работать, но мне было очень удобно использовать поиск и замену REGEX, одноразовые сценарии PERL и аналогичное автоматизированное обслуживание кода, поэтому я предпочитаю стиль кодирования Это не усложняется.

Answer 14

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

Answer 15

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

• Всегда используйте брекеты, если Любые блок if/else if/else Заявление имеет более одной строки. Комментарии подсчитывают, что означает комментарий в любом месте условного означает все разделы условных брекетов.
• По желанию используйте брекеты, когда все Блоки оператора - ровно одна строка.
• Никогда не размещайте условное утверждение на той же линии, что и условие. Строка после оператора IF всегда выполняется условно.

• Если само условное утверждение выполняет необходимое действие, форма будет:

  for (init; term; totalCount++)
  {
      // Intentionally left blank
  }
  

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

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

Answer 16

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

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

Answer 17

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

Answer 18

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

Я тоже не могу предложить лучший контраргумент. Извиняюсь! ;)

Answer 19

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

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

Answer 20

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

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 будет более читабельной. Ответ скорее субъективный.

Answer 21

Ух ты. НИКТО знает о Повеселяясь иначе проблема? Это по сути А Причина для всегда использования брекетов.

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

Эстетика и читаемость не имеют ничего общего.