Подтвердить что ты не робот

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

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

Пример:

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

if(true) continue;

Как и этот

if(true) return;

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

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

Ответ 2

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

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

Ответ 3

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

Приведенные примеры действительны, но они имеют лучшие решения, чем форсирование фигур:

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

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

1) Прокомментируйте if, while и т.д. перед одним слоем с однострочным. То есть лечения

if(foo)
    bar();

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

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

2) Префикс // с помощью ;:

if(foo)
;//    bar();

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

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

Запишите код Python. Это исправит хотя бы некоторые плохие привычки отступов.

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

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

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

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

Принудительные фигурные скобки не помогают найти ошибку в приведенном выше коде.

P.S. Я подписчик на "каждое правило должно сказать, почему" школа, или, как сказал Далай-лама, "Знай правила, чтобы их можно было правильно сломать".

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

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

while (things) 
{
    // stuff
}

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

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

Ответ 7

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

Ответ 8

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

if(!something) doSomethingElse();

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

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

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

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

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

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

Ответ 11

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

if (foo)     
//bar
else     
//baz

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

foo ? bar : baz

и

while (something is true)
{
blah 
}

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

blah while(something is true)

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

Ответ 12

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

Ответ 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);

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

Ответ 14

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

Ответ 15

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

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

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

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

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

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

Ответ 16

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

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

Ответ 17

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

Ответ 18

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

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

Ответ 19

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

С++:

Версия 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;
}

С#:

Версия 1:

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

Version2:

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

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

Ответ 20

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

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

Ответ 21

Ого. NO ONE не знает о болтается еще проблема? Это по существу причина всегда использовать фигурные скобки.

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

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