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

1. Пробел свободен.
2. В зависимости от добавления отступа для будущей удобочитаемости означает в зависимости от установок позиций табуляции, который не является хорошей идеей. Когда-нибудь работавший на десятилетнем коде, который не являлся объектом управления версиями?
3. Мой опыт состоит в том, что любое время, Вы сохраненный, не вводя фигурные скобки больше, чем потеряны дополнительным временем, это берет меня для выяснения то, что Вы имели в виду.

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

if(foo)
bar();
bar(delete);

Вместо

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

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

я нахожу этот самый readable:-

if (foo)
    bar();

и this:-

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

, Если дополнительная строка добавляется к these:-

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

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

А подобный аргумент содержит для для цикла. Однако, когда я запускаю nesting:-

if (foo)
    if (bar)
        snafu()

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

if (foo) {
   if (bar)
       snafu()
}

использования кода, Поскольку я ввожу это, я видел, что ответы спрыгивают 1 - 17, ясно эта попытка быть эмоциональным вопросом (я предлагаю, чтобы Вы добавили субъективный к списку тега (моя способность сделать, это пропало, что произошло с этим?)).

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

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

if (condition1)
if (condition2)
doSomething();
else
doSomethingElse();

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

Я раньше ненавидел фигурные скобки сам. До одного дня я находил использование для них. Я работаю над различными платформами, портирующими приложение от платформы до платформы (работа над 6 всего). На UNIX, если Вам установили энергию, тогда можно легко перейти к окончанию или начало блока кода путем нажатия 'Shift + 5'. Это главным образом то, если/еще блоки или циклы.

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

Paul сказал:

И добавление отступа независимо от использования фигурной скобки.

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

if (something)
  {
    for (i = 0; i < count; i++)
      {
        foo();
      }
  }

Без фигурных скобок, это становится:

if (something
  for (i = 0; i < count; i++)
    foo();

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

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

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

if (something)
{ for (i = 0; i < count; i++)
  { foo();
  }
}

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

if ( any ) {
    DoSomething();
}

if ( any ) { DoSomething(); }

, Если Вы думаете в одной строке, не читаемо настолько хороший, можно записать это в двух строках:

if ( any ) {
    DoSomething(); }
if ( any )
    { DoSomething(); }

• В будущем кто-то должен будет изменить один оператор на большее количество операторов. Без скобок более сложное изменение. Да только littlebit, но лучше, предотвращают ошибки. И запись скобок очень легка дешевый путь.

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

Мои 2 цента:

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

Хорошо мне всегда казалось, что это - больше персонального предпочтения мне. Я заметил однако для удобочитаемости, которую лучше иметь {} затем для не имения их. У меня есть использование уведомления ReSharper, что ReSharper склонен удалять их и делать большинство из Вас, если операторы как это

if(this == yes)
      DoSomething();

, Но для пользы удобочитаемости я всегда делаю

if(this == yes)
{
 DoSomething();
}

, Хотя только с одной строкой кода в, "если" удобочитаемость оператора не действительно отличается, но если Вы помещаете 20-30 строк кода в том, если оператор тогда легче читать с {} там и это оставляет меньше места для ошибки и ошибок в Вашем коде.

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

я не повторю вышеупомянутые аргументы, но я добавлю, я думаю, непротиворечивость: Мне не нравится код как

if (foo)
{
  // Lot of code
}
else
  DoStuff();

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

if (somethingBadHappened)
  return;

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

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

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

С одной стороны, я пропускаю фигурные скобки для отдельного оператора. С другой стороны, я проверяю весь код C с Линтом ПК ( http://www.gimpel.com/ ), который отмечает две или больше строки с отступом после если () оператор как "подозрительное добавление отступа".

Между прочим, помещая отдельных операторов на ту же строку как, если () похож на хорошую идею.

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

for (int i=0; i<10; i++) 
{
    for (int x=0; x<20; x++) 
    {
        if (someBoolValue)
            DoThis(x,y);
    }
}

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

нет абсолютно никакого смысла в записи

using (Stream x = File.Open(...)) 
{
    using (Stream y = File.Create(...)) 
    {
        ...
    }
}

, когда можно записать

using (Stream x = File.Open(...))
using (Stream y = File.Create(...)) 
{
    ....
}

Мне нравится более компактное форматирование также. Поэтому я постоянно поражаю Ctrl+K, Ctrl+D для переформатирования в Visual Studio. Мне просто жаль, что я не мог заставить его сделать это для меня после каждого нажатия клавиши.

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

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

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

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

if( foo )
    bar();

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

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

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

Еще имейте Вас мысль об исследовании этой опции для одной строки если оператор:

(!a) ? Foo() : Bar();

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

Без фигурных скобок:

if(DoSomething)
    MyClass myClass = new MyClass();

myClass.DoAnythingElse();

Это скомпилирует, но приведет к нулевым ссылкам легко. (Компилятор C# не компилирует это, хорошую вещь!)

принимая во внимание, что этот путь:

if(doSomething)
{
    MyClass myClass = new MyClass();
}

myClass.DoAnythingElse();

даже не скомпилирует.

Это уже намного лучше, чем minize Исключения во время компиляции, чем нахождение их во времени выполнения.

Потому что StyleCop так говорит.

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

if (mybool)
{
  doMyStuff();
}
else
{
  doMyOtherStuff();
  checkStuff();
}

, а НЕ как

if (mybool) {
  doMyStuff();
}
else {
  doMyOtherStuff();
  checkStuff();
}

, а не как

   if (mybool)
     doMyStuff(); 
   else 
   {  
     doMyOtherStuff();
     checkStuff(); 
   }

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

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