Каков предпочтительный стиль для отдельных заявлений о принятии решений и действиях?

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

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

но это священная война.

Я рекомендую

if(a==b)
{
    doSomething();
}

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

if(a==b)
    doSomething();
    doSomethingElse();

очень отличается от

if(a==b)
{
    doSomething();
    doSomethingElse();
}

дополнительную информацию смотрите в статье Джоэла

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

if(something)
 DoOneThing();
else
  DoItDifferently();

а затем решите добавить еще одну операцию в предложение else и забудьте завернуть его в фигурные скобки:

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

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

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

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

Но если у вас есть только несколько лайнеров:

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

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

Это также относится к циклическим конструкциям и тому подобному:

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

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

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

И до того, как остряки доберутся до него, нет, причина не была "everyone always uses braces".

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

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

На самом деле это не имеет значения, пока вы с этим согласны.

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

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

if (var == 1)
  doSomething();
doSomethingElse();

Теперь приходит кто-то, кто на самом деле не уделяет достаточно внимания и решает, что что-то дополнительное должно произойти, если (var == 1), поэтому они делают это:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

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

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

Я лично поддерживаю объяснение McConnell из кода Complete.

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

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

Начните писать такие вещи, как:

If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

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

В основном найдите тот, который вам удобно писать каждый раз, и придерживайтесь его. Я действительно верю в использование разделителей блоков ('{ ' ,'}'), насколько это возможно.

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

If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

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

Как уже упоминали другие, выполнение оператора if в двух строках без скобок может привести к путанице:

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

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

if (a == b) DoSomething();

а в остальное время я пользуюсь брекетами.

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

var c = (a == b) ? DoSomething() : DoSomethingElse();

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

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

Все еще более лаконично, чем блок if/else, но легко увидеть, что происходит.

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

В этом случае я удостоверяюсь, что это одно утверждение, сохраняя все на одной линии, как это:

if (aString) free(aString);

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

Ruby красиво устраняет один вопрос в дискуссии. Стандарт для ОДН-вкладыша является:

do_something if (a == b)

а для многострочного:

if (a == b)
  do_something
  do_something_else
end

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

Это (пока) не доступно в Java, как и во многих других языках, AFAIK.

Соглашения Sun о коде для языка программирования Java говорят об этом :

Класс операторов if-else должен иметь следующую форму:

if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

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

Когда я дома, у меня есть две формы.

Первая-это одиночная линия:

if (condition) doThis();

а второй - для нескольких строк:

if (condition) {
   doThis();
}

Наш босс заставляет нас ставить { } после заявления о принятии решения, несмотря ни на что, даже если это одно заявление. Это действительно раздражает, чтобы добавить две дополнительные строки. Единственным исключением являются тернарные операторы.

Я думаю, что это хорошо, что у меня есть мой монитор кода в портретной ориентации на 1200x1600.

Я склонен согласиться с Джоэлом Сполски в этой статье ( делая неправильный код неправильным) со следующим примером кода :

if (i != 0)
bar(i);
foo(i);

Фу теперь безоговорочен. А это очень плохо!

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

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

if (cond)
   {
   //statement
   }

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

Да, я тоже люблю делать отступы в скобках до уровня блока.

Python хорош тем, что отступ определяет блок. В таком языке вопрос спорный.

Раньше я шел по линии "use curly braces always", как аппаратчик. Однако я изменил свой стиль, чтобы исключить их в однострочных условных выражениях:

if(!ok)return;

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

if(!ok){

    do();

    that();

    thing();
}

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

В Perl, если вы делаете простой тест, когда-нибудь вы напишете его в этой форме:

do_something if condition;

do_something unless condition;

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

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}