这不是一场神圣的战争，这不是"哪个更好"的问题。

if语句对单个语句使用以下格式的优点是什么？

if (x) print "x is true";

if(x) 
    print "x is true";

相对于

if (x) { print "x is true"; }
if(x) {
    print "x is true";    
}

如果我们格式化没有括号的单个语句，或者知道有这样的程序员，那么首先导致我们/他们采用这种风格的原因是什么？我特别想知道这给我们带来了什么好处。

更新：由于最受欢迎的答案忽略了实际问题(即使它提供了最明智的建议)，因此这里是无括号专家的综述。

• 紧凑
• 对某些人更具可读性
• 括号调用作用域，在某些情况下具有理论上的开销

解决方案

我强烈不喜欢将if的测试和正文放在同一行的任何样式。

这是因为共享行使得在许多调试器中无法在if主体上设置断点，因为断点通常基于行号。

空格是朋友....

但话又说回来，我喜欢：

if (foo)
{
    Console.WriteLine("Foobar");
}

我发现：

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

比这更好：

if( true )
    DoSomething();
else
    DoSomethingElse();

这样，如果我(或者其他人)稍后返回此代码以将更多代码添加到分支之一，则不必担心忘记将代码括在花括号中。我们的眼睛会在视觉上看到缩进作为我们正在尝试做的线索，但大多数语言不会。

我总是用

if(x) 
{
    print "x is true";    
}

省略花括号会导致某些人错误地维护代码，以为如果他们在当前行之后添加一行，则会认为他们正在将它们添加到if子句中。

if
{
// code
}
else 
{
// else code
}

因为我喜欢代码块排列起来(包括它们的花括号)。

对我来说，花括号使查看程序流程更加容易。这也使将语句添加到if语句的主体变得更加容易。如果没有大括号，则必须添加大括号以添加另一个语句。

我猜不使用花括号的优点是它看起来更干净，并且我们不会在花括号时浪费时间。

行间距和缩进可以大大提高可读性。

就可读性而言，我更喜欢以下内容：

// Do this if you only have one line of code
// executing within the if statement
if (x)
    print "x is true";

// Do this when you have multiple lines of code
// getting executed within the if statement    
if (x)
{
    print "x is true";
}

如果我编码：

if(x) 
    print "x is true";

并且6个月后需要添加新行时，花括号的出现使我键入的可能性大大降低

if(x) 
    print "x is true";
    print "x is still true";

与以下情况相比，这将导致逻辑​​错误：

if(x) { 
    print "x is true";
    print "x is still true";
}

我发现，花括号使这种逻辑错误更易于阅读和避免。

我更喜欢方括号样式，主要是因为它可以使眼睛清楚地知道起点和终点。它使查看语句中实际包含的内容变得更加容易，并且它实际上是一个if语句。也许是一件小事，但这就是我使用它的原因。

只要我们所在团队中的团队保持一致，那就没关系

每个人都做同样的事情是主要的

我用

if (cond) {
  ...
} else {
  ...
}

• 一切都应该始终带有大括号。即使现在if块中只有一行，我以后也会添加更多。
• 我不会将大括号放在自己的行上，因为这毫无意义地浪费了空间。
• 我很少将代码块与可读性放在同一行。

if (x)
{
    print "x is true";
}

在同一列中打开和关闭括号，可以轻松找到不匹配的括号，并在视觉上隔离该块。在与" if"相同的列中打开花括号，可以很容易地看到该块是有条件的一部分。由仅包含大括号的行所创建的块周围的多余空白使得在略读代码时可以很容易地从逻辑结构中挑选出它。当人们稍后编辑代码并误读哪些语句是条件语句的一部分以及哪些不是缩进语句时，始终明确使用大括号可以避免出现问题，但可能会与现实不符，但将大括号括起来总是可以的。

如果我们(或者其他维护或者更改代码的编码人员)需要在该条件块的某些部分添加语句，则将单行if语句括起来具有使我们免于头痛的理智的优势。

如果语句缺少括号，则使用单个语句：

优点：

• 更少的字符
• 更干净的外观

缺点：

• 均匀性：并非所有块看起来都一样
• 将语句添加到块中时潜在的错误：用户可能会忘记添加花括号，而if不会覆盖新语句。

As in:

if(x) 
    print "x is true";
    print "something else";

无论如何，这就是我要走的路！看起来最好。

If(x)
{
    print "Hello World !!"
}
Else
{
    print "Good bye!!"
}

如果我们想知道各种代码格式样式的名称是什么，Wikipedia上有一篇有关缩进样式的文章。

乔尔·斯波斯基(Joel Spolsky)写了一篇好文章：使错误的代码看起来错误

他专门解决了这个问题

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

  
  In this case the code is 100% correct;
  it conforms to most coding conventions
  and there’s nothing wrong with it, but
  the fact that the single-statement
  body of the ifstatement is not
  enclosed in braces may be bugging you,
  because you might be thinking in the
  back of your head, gosh, somebody
  might insert another line of code
  there

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

  
  … and forget to add the braces, and
  thus accidentally make
  foo(i)unconditional! So when you see
  blocks of code that aren’t in braces,
  you might sense just a tiny, wee,
  soup?on of uncleanliness which makes
  you uneasy.

他建议你

… deliberately architect your code
  in such a way that your nose for
  uncleanliness makes your code more
  likely to be correct.

如果我们执行以下操作：

if(x)
{
    somecode;
}
else
{
    morecode;
}

这对于源代码控制和预处理器指令更好
可以使用很长一段时间的代码。添加#if左右而不添加它会更容易
无意间破坏了语句或者不得不添加额外的行。

习惯有点奇怪，但经过一段时间后效果很好
尽管。

我希望IDE可以强制执行此行为。正如我们正确指出的那样，没有"正确"的行为。一致性更重要...这可能是两种风格。

我用

if (x)
{
    DoSomething();
}

多行，但我更喜欢无括号的衬板：

if (x)
   DoSomething();
else
   DoSomethingElse();

我发现多余的括号在视觉上令人反感，但我从未做过
上述错误之一是在添加另一条语句时未添加方括号。

严重的是，这是我们最后一次在任何代码中的任何地方出现错误的原因是：

if (a)
  foo();
  bar();

是的，永远不会... *这里唯一真正的"专业"是匹配周围代码的样式，并将美学之战留给刚大学毕业的孩子们。

*(caveat是foo(); bar();是宏扩展，但这是使用宏的问题，而不是使用ifs的花括号)

在函数开始时测试中断条件时，我倾向于只使用单行，因为我喜欢使这段代码尽可能简单和整洁

public void MyFunction(object param)
{
     if (param == null) return;

     ...
}

另外，如果我确实想避免使用花括号并内联if子句代码，则可以将它们单行显示，这样对于在if中确实需要添加方括号的人来说很明显

像Matt(上面的3)一样，我更喜欢：

if (x)
{
    ...statement1
    ...statement2
}

和

if (x)
    ...statement
else
    ...statement

我认为有些人以后可能会出现而又没有意识到他们必须添加大括号以形成多行if块，这很奇怪。如果这超出了他们的能力，我想知道还有其他事情！

当不需要它们时，我不喜欢使用花括号。我觉得它会使方法中的行数膨胀并使它变得不可读。所以我几乎总是去做以下事情：

if (x)
   print "x is true"
for (int i=0; i<10; i++)
   print "y is true"

依此类推。如果有人需要添加另一条语句，则只需添加花括号即可。即使我们没有Ror类似的东西，这也是很小的一笔交易。

尽管如此，在某些情况下，即使语句中只有一行，也就是如果该行特别长，或者如果我需要在" if"中添加注释，我都将使用大括号。基本上，我只是用看起来更好的东西来查看。

如果是if的一行(可能是其他的一行)，我宁愿不使用方括号。它更具可读性和简洁性。我说我更喜欢它，因为这纯粹是一个优先事项。尽管我认为试图强制执行必须始终使用花括号的标准有点愚蠢。

如果我们要担心有人在if语句的主体中添加另一行而不是不添加(仅在那时才需要)大括号，那么我认为问题比拜占庭式编码标准大。

if (x) {
    print "x is true";    
}
else {
    do something else;
}

我总是大括号。这只是一个好习惯。与思考相比，打字不是"工作"。

注意条件之前的空格。这有助于使其看起来不像方法调用。

始终使用花括号是个好主意，但始终给出标准答案："如果有人添加一行代码而忘记添加花括号怎么办？"是一个相当薄弱的原因。

从一开始就没有括号可以引入一个细微的错误。这发生在我身上几次，我也看到过发生在其他程序员身上。

它从一个简单的if语句开始就足够无辜了。

if (condition)
    do_something();
else
    do_something_else();

一切都很好。

然后有人来给if添加另一个条件。他们不能使用&&将它添加到if语句本身，因为逻辑不正确，因此他们添加了另一个if。我们现在有：

if (condition)
    if (condition2)
        do_something();
else
    do_something_else();

看到问题了吗？它可能看起来正确，但是编译器对它的看法有所不同。它看起来像这样：

if (condition)
    if (condition2)
        do_something();
    else
        do_something_else();

这意味着完全不同的东西。编译器不关心格式。否则以最接近的if表示。另一方面，人类依赖于格式设置，因此很容易错过该问题。

到目前为止，我感觉已经投票了，但我将担保以下其中一项：

if (expr) {
   funcA();
}
else {
   funcB();
}

或者，为便于阅读，在有限情况下的速记：

if (expr) funcA();
else funcB();

对我来说，速记格式很不错，当我们希望它像英语语法一样阅读时。如果代码看起来可读性不足，我将分头讲解：

if (expr)
   funcA();
else
   funcB();

仔细考虑后，我不会在" if" /" else"块中放置嵌套条件，以避免编码器/编译器产生歧义。如果它比这更复杂，那么我在if和else块上都使用大括号。

/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
    return(0);
}else{
    return(-1);
}

我从来没有在制表符之外使用多余的空格，但总是将方括号包括在内可以节省大量时间。

似乎唯一可以接受的是在方法开始时检查变量的参数：

public int IndexOf(string haystack, string needle)
{
    // check parameters.
    if (haystack == null)
        throw new ArgumentNullException("haystack");
    if (string.IsNullOrEmpty(needle))
        return -1;

    // rest of method here ...

唯一的好处就是紧凑。很明显，程序员不必遍历不必要的{}：

• 该方法在任何真实分支上退出
• 很明显，这些都是一线

就是说，出于他人的原因，我将始终{}编写程序逻辑。当放下花括号时，很容易在不存在的情况下在脑子上花括号，并引入细微的代码缺陷。

此类型的任何格式都可以。人们会为此与我们争论，因为这很容易理解。人们喜欢谈论他们了解的事物，而不是处理诸如设计良好和使用新算法解决难题之类的更大问题。对于单一的衬纸，我倾向于不使用方括号。但是，我也很高兴将其与方括号一起阅读。如果给定项目有特定的样式指南，则我希望遵循该指南。我相信某些主观正确性的一致性。

我个人选择不使用单引号括起来，是因为键入的字符更少，代码更短且简洁。

在提供的选项中，我会选择

if (x) {
  print "x is true";    
}

仅仅因为大括号是习惯打字。

但实际上，作为一个主要是Perl的程序员，我更有可能使用

print "x is true" if x;

(当我使用不支持后缀条件的语言时，总是使我感到震惊。)

我更喜欢没有括号的单行语句，我知道有危险，当我插入一行新代码时，可能会忘记添加它们，但是我不记得上一次发生这种情况。我的编辑器(vim)阻止我编写如下内容：

if (x)
    x = x + 1;
    printf("%d\n", x);

因为它会以不同的方式缩进。我唯一遇到的问题是糟糕的书面宏：

#define FREE(ptr) {free(ptr); ptr = NULL;}

if (x)
    FREE(x);
else
    ...

当然这是行不通的，但是我认为最好修复宏，以避免出现那些可能的错误或者问题，而不是更改格式样式。

因此，这种格式化方式可能会出现问题，但是它们并不是致命的。最终成为一个品味问题。

我还没有看到有人提到将括号与emacs中的if -bracket匹配放在同一行的最有用的理由。将光标放在结束括号上时，emacs将显示带有匹配开始括号的行。将起始括号放在自己的行上会否定该功能。

我更喜欢以下内容...我认为它看起来更干净。

if(x)
{
    code;
}
else
{
     other code;
}

我不喜欢使用以下关键字在同一行上关闭大括号：

if (x) {
    print "x is true";    
} else {
    do something else;
}

这使得仅删除else子句变得更加困难。通过将follow关键字放在下一行，例如，我可以利用允许我选择一系列行并对所有行进行注释/取消注释的编辑器。

if (x) {
    print "x is true";    
}
//else {
//    do something else;
//}

我总是喜欢这样：

if (x) doSomething();

if (x) {
    doSomthing();
    doOtherthing();
}

但始终取决于我们所使用的语言和操作。有时我喜欢戴括号，有时不喜欢。取决于代码，但是我编码必须写一次，重写十遍和阅读一百遍；因此，只需按照自己的意愿去做，就可以更快地阅读和理解。

我想我比我想象的更离群了。我还没有注意到这一点。

我是的粉丝

if (x)
{ foo(); }

它感觉紧凑且可读(我讨厌花括号)，但它使条件的范围变得明确。

与单行if相比，它对断点更友好。在我的大括号换行符世界中，它也让我们感到宾至如归：

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

编辑：看来我误解了原始问题，所以这个答案离题。不过，我仍然对任何回应感到好奇。

一个衬里就是...一个衬里，应该像这样保持：

if (param == null || parameterDoesNotValidateForMethod) throw new InvalidArgumentExeption("Parameter null or invalid");

例如，我喜欢这种用于参数检查的样式，它紧凑且通常易于阅读。我过去经常把花括号放在缩进的代码上，但发现在许多琐碎的情况下，它只是在监视器上浪费了空间。在某些情况下，放下牙套可以让我更快地掌握方法的内容，并使整体演示更轻松。但是，如果更多地参与其中，那么我会像对待其他所有事情一样对待它，并且会像这样大括号：

if (something)
{
    for(blablabla)
    {
    }
}else if
{
 //one liner or bunch of other code all get the braces
}else
{
  //... well you get the point
}

话虽这么说...我鄙视括号在同一行上，如下所示：

if(someCondition) { doSimpleStuff; }

最坏的

if(somethingElse){
  //then do something
}

它更紧凑，但我发现很难跟踪括号。

总的来说，这只是一个个人品味的问题，只要它不采用某种非常奇怪的方式来缩进和支撑即可。

if(someStuff)
        {
  //do something
        }