Почему это считают плохой практикой для исключения фигурных скобок? [закрытый]

177
задан 5 revs, 4 users 80% 19 August 2016 в 17:07
поделиться

51 ответ

На самом деле единственное время, которое это когда-либо действительно, укусило меня, был, когда я отлаживал и прокомментировал панель ():

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

Кроме этого, я склонен использовать:

if(foo) bar();

, Который заботится о вышеупомянутом случае.

РЕДАКТИРОВАНИЕ спасибо за разъяснение вопроса, я соглашаюсь, мы не должны писать код к наименьшему общему знаменателю.

181
ответ дан 2 revs 23 November 2019 в 20:17
поделиться

Допустите ошибку на стороне более безопасных - просто еще одна ошибка, которую Вы потенциально не должны будете исправлять.

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

, Если у меня есть острота, я обычно форматирую ее следующим образом:

if( some_condition ) { do_some_operation; }

, Если строка является просто слишком громоздкой тогда, используют следующее:

if( some_condition )
{
    do_some_operation;
}
3
ответ дан Jordan Parmer 23 November 2019 в 20:17
поделиться

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

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

я вижу его отчасти как аргумент в пользу if ( foo == 0 ) по сравнению с if ( 0 == foo ). Последний может предотвратить ошибки для новых программистов (и возможно даже иногда для ветеранов), в то время как первого легче быстро считать и понять, когда Вы поддерживаете код.

5
ответ дан Marc Charbonneau 23 November 2019 в 20:17
поделиться

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

if (...) {
    foo();
    bar();
}
else {
    ...
}
6
ответ дан 2 revs 23 November 2019 в 20:17
поделиться

Большинство раз это внушено как стандарт кодирования, ли для компании или проекта FOSS.

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

кроме того, предположите, что кто-то идет между Python и языком Cish несколько раз день... В Python расположение с отступом является частью блока symantics языка, и было бы довольно легко сделать ошибку как та, которую Вы заключаете в кавычки.

4
ответ дан joshperry 23 November 2019 в 20:17
поделиться

Скажем, у Вас есть некоторый код:

if (foo)
    bar();

и затем кто-то еще приезжает и добавляет:

if (foo)
    snafu();
    bar();

Согласно пути это записано, панель (); теперь выполняется безусловно. Включением фигурных скобок Вы предотвращаете этот вид случайной ошибки. Код должен быть написан таким способом как, чтобы сделать такие ошибки, трудные или невозможные сделать. Если бы я делал обзор кода и видел недостающие фигурные скобки, особенно распространенные через несколько строк, то я создал бы дефект. В случаях, где это выравнивается по ширине, сохраните его на одной строке так, чтобы шанс совершения такой ошибки был снова сведен к минимуму.

6
ответ дан Elie 23 November 2019 в 20:17
поделиться

Скорость чтения...

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

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Немного быстрее, чем я читал:

if (condition) DoSomething();

DoSomethingElse();

я считал его немного медленнее, если это похоже на это:

if (condition) DoSomething();
DoSomethingElse();

я считал это значительно медленнее, чем предшествующее:

if (condition) 
    DoSomething();
DoSomethingElse();

beause я не могу не считать его снова на всякий случай и задаться вопросом, предназначил ли автор:

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

Уже покрытый в целом, но когда дело доходит до [1 114] чтение ниже, я буду изучать это долгое время для проверки, что предназначил автор. Я могу даже выследить исходного автора для подтверждения.

if (condition) 
    DoSomething();
    DoSomethingElse();
155
ответ дан 2 revs 23 November 2019 в 20:17
поделиться

Если это - что-то маленькое, запишите это как это:

if(foo()) bar();

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

53
ответ дан Adam Jaskiewicz 23 November 2019 в 20:17
поделиться

Я предпочитаю ясность, которую предлагает изогнутая фигурная скобка. Вы знаете точно, что предназначено и не должно предполагать, попал ли кто-то просто впросак и оставил их (и представил ошибку). Единственное время я опускаю их, - когда я поместил если и действие с той же строкой. Я не делаю этого очень часто также. Я на самом деле предпочитаю пробел, представленный путем помещения изогнутой фигурной скобки на ее собственную строку, хотя с лет K& R подобное C программирование, заканчивая строку фигурной скобкой практика, которую я должен работать, чтобы преодолеть, если IDE не осуществляет его для меня.

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}
35
ответ дан tvanfosson 23 November 2019 в 20:17
поделиться

Это не всегда считают плохой практикой. Моно Проект, Кодирующий Инструкции , предлагает не использовать фигурные скобки, если это не необходимо. То же для Стандарты Кодирования GNU . Я думаю, что это - вопрос персонального вкуса как всегда с кодированием стандартов.

35
ответ дан Manuel Ceron 23 November 2019 в 20:17
поделиться

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

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

if(a)
   if(b)
     c();
else
   d();

Вы замечали, что выражение else является на самом деле выражением else "если (b)"? Вы, вероятно, сделали, но Вы будете доверять кому-либо, чтобы быть знакомыми с этим глюком?

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

46
ответ дан FredV 23 November 2019 в 20:17
поделиться

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

Как правило, если я не разрабатываю некоторых абсолютно ресурс / важное приложение скорости, я всегда допускал бы ошибку на стороне записи кода, который является

(a) Легкий для любого другого разработчика следовать за тем, что я делаю

(b) Комментарий определенные части кода, которому, возможно, понадобится он

(c) Легкий отладить, если что-то идет неправильно

(d) Легкий изменить, если это должно быть в будущем (т.е. добавляющий / удаляющий код)

, скорость или академическая элегантность кода вторичны к этим факторам с Бизнес-точки зрения. Нельзя сказать я намеревался писать неуклюжий или ужасный код, но это - МОЙ порядок очередности.

Путем исключения фигурных скобок в большинстве экземпляров, это для меня делает (b), (c) и (d) более трудный (отметьте не невозможный однако). Я сказал бы, что использование фигурных скобок или не не имеет эффект на (a).

35
ответ дан Jayden 23 November 2019 в 20:17
поделиться

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

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

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

я предпочитаю

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}
23
ответ дан Maghis 23 November 2019 в 20:17
поделиться

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

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

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

Теперь, не понимайте меня превратно, я не говорю, что необходимо всегда делать {} только для предотвращения этой проблемы в C/C++, но я должен был иметь дело с некоторыми очень странными ошибками из-за этого.

15
ответ дан Torlack 23 November 2019 в 20:17
поделиться

Я использую для размышления того же пути.

До одного дня (почему там всегда, что "один день", который изменяет Вашу жизнь навсегда?) мы тратим с 24 - 36 часов прямо безо сна, отлаживая производственный код только, чтобы узнать, что кто-то не помещал фигурные скобки, объединенные с изменением поиска/замены.

Это было что-то вроде этого.

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

то, Что прибыло после, было

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

, оказывается, что система генерировала 500 МБ журналов ежедневно, и нас попросили остановить его. Флаг отладки был недостаточно так поиск, и замена println был в порядке.

Все еще, когда приложение перешло к производству, флаг отладки был выключен, и важный "saveDayData" никогда не называли.

РЕДАКТИРОВАНИЕ

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

if( object != null ) try { 
     object.close();
} catch( .....

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

15
ответ дан 2 revs 23 November 2019 в 20:17
поделиться

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

6
ответ дан plinth 23 November 2019 в 20:17
поделиться

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

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

10
ответ дан chills42 23 November 2019 в 20:17
поделиться

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

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

Иначе, у меня нет проблемы с ним.

10
ответ дан 3 revs 23 November 2019 в 20:17
поделиться

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

я видел

if (...)
    foo();
    bar();

, ошибка кусает меня (или скорее "меня и коллег" - я на самом деле не представлял ошибку) однажды . Это было то, несмотря на то, что наши стандарты кодирования, в то время рекомендуется использование фигурных скобок везде. Мне потребовалось удивительно долгое время для определения - потому что Вы видите то, что Вы хотите видеть. (Это было приблизительно 10 лет назад. Возможно, я нашел бы его быстрее теперь.)

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

10
ответ дан 2 revs, 2 users 95% 23 November 2019 в 20:17
поделиться

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

я предполагаю, что это означает, что я не умен. Я сделал ошибки вокруг этого многократно. Я отладил ошибки других вокруг этого. Я наблюдал, что программное обеспечение поставлется с ошибками из-за этого (RDP к машине, выполняющей VS2002, и Ваш шрифт окна часов пойдет wonky).

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

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

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

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

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

  • Рефакторинг и выразительность языка средний, что мои блоки намного короче, и однострочные блоки, происходят намного чаще, чем привыкший к. Гипотетически, с безжалостным приложением ExtractMethod, я мог возможно иметь [только 111] однострочные блоки в моей целой программе. (Интересно, на что это было бы похоже?)

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

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

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

10
ответ дан 2 revs 23 November 2019 в 20:17
поделиться

Из этих трех соглашений:

if(addCurleyBraces()) bugFreeSofware.hooray();

и:

if(addCurleyBraces())
    bugFreeSofware.hooray();

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

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

я предпочитаю последний как:

  • я нахожу легче читать, если все операторы "if" записаны универсальным способом.
  • Это может сделать программное обеспечение крошечным битом более устойчивый и ошибка свободный. Однако и усовершенствованные текстовые редакторы всего современного IDE имеют хорошие функции автоматического отступа, которые я думаю, что все должны использовать, пока это не портит форматирование комментария или идет вразрез со стандартами команды (в большом количестве случаев, возможно создать пользовательскую схему форматирования и совместно использовать его с командой). Моя точка здесь - то, что, если добавление отступа сделано правильно, риск введения ошибки снижен немного.
  • я предпочитаю, чтобы булево выражение и оператор (операторы) выполнились, чтобы быть на различных строках. Мне нравится быть в состоянии отметить строку для отладки целей. Даже если я использую IDE, где я могу отметить оператор и ступить в него, это - интерактивная операция, и я мог бы забыть, где я начал отлаживать, или по крайней мере мне потребуется немного больше времени для продвижения через код несколько раз (поскольку я должен отметить положение вручную каждый раз во время отладки).
9
ответ дан user14070 23 November 2019 в 20:17
поделиться

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

Строки (почти) свободны, минимизирование количества строк в Вашем коде не должно быть целью.

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

8
ответ дан 2 revs 23 November 2019 в 20:17
поделиться

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

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

if(x < y)
    x = y;
else
    y = x;

И другой как это;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

я предпочитаю просто выбирать один общий стиль и придерживаться его:)

8
ответ дан Christopher McAtackney 23 November 2019 в 20:17
поделиться

Один из основных вопросов - когда у Вас есть регионы острот и неодного лайнеров, наряду с разделением от управления statment (for, if, что имеет Вас), и конец statment.

, Например:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}
7
ответ дан rampion 23 November 2019 в 20:17
поделиться

Я раньше был огромным сторонником "фигурных скобок, НЕОБХОДИМОСТЬ!", но начиная с принятия поблочного тестирования, я нахожу, что мои модульные тесты защищают операторы без фигурной скобки от сценариев как:

if (foo)
    snafu();
    bar();

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

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

if (foo) snafu();

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

7
ответ дан Liggy 23 November 2019 в 20:17
поделиться

Используйте некоторое персональное решение.

if (foo)
  bar();

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

if (foo)
  bar();
  baz();

, Если Вы не волнуетесь по поводу идиотов, Вы в порядке (я не - если они не могут разобраться в синтаксисе абсолютного кода, это - наименьшее количество их проблем),>

В обмен, это намного более читаемо.

Остальная часть времени:

if (foo) {
  bar();
  baz();
}

, Который был моим фаворитом, пока я могу помнить. Дополнительно:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Работы для меня.

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

7
ответ дан lally 23 November 2019 в 20:17
поделиться

Моя философия - то, если она делает код более читаемым, почему бы не это?

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

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

10
ответ дан 2 revs 23 November 2019 в 20:17
поделиться

Хорошо, это старый вопрос, на который дан смертельный ответ. Мне есть что добавить.

Сначала я просто должен сказать ИСПОЛЬЗУЙТЕ ОПОРА. Они могут только улучшить читаемость, а читаемость (для вас и других!) Должна быть очень важной в вашем списке приоритетов, если вы не пишете ассемблер. Нечитаемый код всегда, всегда приводит к ошибкам. Если вы обнаружите, что фигурные скобки заставляют ваш код занимать слишком много места, вероятно, ваши методы слишком длинные. Большая часть или все методы должны умещаться в пределах одной высоты экрана, если вы все делаете правильно, и Find (F3) - ваш друг.

Теперь к моему добавлению: существует проблема с этим:

if (foo) bar();

Попробуйте установить точка останова, которая будет достигнута, только если bar () будет запущен. Вы можете сделать это в C #, поместив курсор на вторую половину кода, но это не очевидно и немного неудобно. В C ++ вы не могли не делаю этого вообще. По этой причине один из наших самых опытных разработчиков, работающих над кодом C ++, настаивает на том, чтобы разделить операторы if на две строки. И я согласен с ним.

Итак, сделайте следующее:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}
7
ответ дан 23 November 2019 в 20:17
поделиться

Откровенно говоря, я вижу это так:

Хорошие программисты защищаются, плохие - нет.

Поскольку есть несколько примеров выше и мой собственный аналогичный опыт с ошибками, связанными с забыв о скобках, я на собственном горьком опыте научился ВСЕГДА ставить скобы.

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

Джоэл даже упоминает об этом в Как сделать неправильный код неправильным

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

13
ответ дан 23 November 2019 в 20:17
поделиться

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

if(foo)
   {DoSomething();}

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

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

2
ответ дан Steve Melnikoff 23 November 2019 в 20:17
поделиться