Почему считается плохой практикой опускать фигурные скобки?

Допустим, у вас есть код:

if (foo)
    bar();

а потом приходит кто-то другой и добавляет:

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

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

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

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

Вместо

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

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

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

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

В остальном у меня с этим проблем нет.

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

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

Помимо этого, я обычно использую:

if (foo) bar();

Что заботится о вышеуказанном случае.

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

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

Я видел

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

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

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

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

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

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

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

Например:

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
}

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

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

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

Мои 2 цента:

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

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

if (...) {
    foo();
    bar();
}
else {
    ...
}

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

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

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

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

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

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

Раньше я был ярым сторонником «фигурных скобок - ОБЯЗАТЕЛЬНО!», Но с тех пор, как я принял модульное тестирование, я обнаружил, что мои модульные тесты защищают операторы без фигурных скобок от таких сценариев, как:

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

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

В качестве альтернативы, для чего-то подобного выше, я бы, вероятно, встроил это так:

if (foo) snafu();

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

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

if (foo()) bar();

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

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

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

if (condition) // normal/standard for me
{
   action();
}

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

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

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

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

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

Я нахожу это очень читаемым: -

if (foo)
    bar();

и это:-

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

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

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

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

Аналогичное рассуждение справедливо и для цикла for. Однако когда я начинаю вложение: -

if (foo)
    if (bar)
        snafu()

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

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

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

Самое важное - это согласовать в команде, насколько это приемлемо, и придерживаться его.

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

Без подтяжек:

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

myClass.DoAnythingElse();

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

Тогда как так:

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

myClass.DoAnythingElse();

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

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

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

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

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
}

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

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

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

if (myCondition) BADLY_MADE_MACRO(myValue)

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

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

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

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

if ( some_condition ) { do_some_operation; }

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

if ( some_condition )
{
    do_some_operation;
}

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

if (this == yes)
      DoSomething();

Но для удобства чтения я всегда делаю

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

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

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

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

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

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

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

Вы думали об изучении этой опции для однострочного оператора if else:

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

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

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

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

И еще один такой;

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

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

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

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

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

Сказав это, иногда я балуюсь без подтяжек: в условиях охраны, когда я делаю ранний выход:

if (somethingBadHappened)
  return;

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

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

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

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

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

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

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

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

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

(d) Легко изменить, если это потребуется в будущем (например, добавление / удаление кода)

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

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

С одной стороны, я оставляю фигурные скобки для одного утверждения. С другой стороны, я проверяю весь код C с помощью PC-Lint (http://www.gimpel.com/), который помечает две или более строк с отступом, следующих за оператором if (), как «подозрительный отступ».

Кстати, размещение отдельных операторов в одной строке с if () выглядит хорошей идеей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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(...)) 
{
    ....
}

Павел сказал:

And indentation is independent of brace usage.

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

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

Без скобок это становится:

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

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

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

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

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

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

Из трех условностей:

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

а также:

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

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

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

Я предпочитаю последний вариант:

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

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

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

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Чуть быстрее, чем я читал:

if (condition) DoSomething();

DoSomethingElse();

Я читаю немного медленнее, если это выглядит так:

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

Я читаю это значительно медленнее, чем предыдущее:

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

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

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

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

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

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

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

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

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

if (foo)
   {DoSomething();}

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

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

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

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

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

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

if ( foo )
    bar();

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

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

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

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

Так что, если бы я смотрел на проблему Рэмпиона на vim, я бы совершенно потерялся, и мне потребовалось бы время, чтобы полностью понять код.

Используйте личное суждение.

if (foo)
  bar();

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

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

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

Зато он намного читабельнее.

Оставшееся время:

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

Сколько себя помню, это было моим любимым. Кроме того:

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

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

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

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

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

Я привык думать так же.

До одного дня (почему всегда есть тот «один день», который навсегда меняет вашу жизнь?) Мы проводим от 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 / try.

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

После того, как это сделал суперзвезда-разработчик.

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

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

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

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

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

и НЕ нравится

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

и не нравится

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

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

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

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

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

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

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

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

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

Я очень рад:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Лично я не понимаю, почему

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

уже не читается.

Да, строки бесплатны, но зачем мне пролистывать страницы и страницы кода, если он может быть вдвое меньше?

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

Кроме того, я поставлю всегда фигурные скобки для вложенных if, где я вложил else

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

против

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

ужасно сбивает с толку, поэтому я всегда пишу это так:

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

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