为什么省略花括号被认为是不好的做法？[关闭]

为什么每个人都告诉我编写这样的代码是一种不好的做法？

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

关于省略花括号的最大论据是，有时花括号可能是花括号的两倍。例如，以下代码为C＃中的标签绘制发光效果。

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

您还可以获得链接usings在一起的额外好处，而不必缩进一百万次。

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

花括号的最常见参数围绕维护编程，以及在原始if语句及其预期结果之间插入代码会引起的问题：

if (foo)
    Bar();
    Biz();

问题：

1. 想要使用该语言提供的更紧凑的语法是错误的吗？设计这些语言的人很聪明，我无法想象他们会使用一个总是很难使用的功能。
2. 我们应该还是不应该编写代码，以便最低公分母可以理解并且在使用它时没有问题？
3. 我还有其他说法想念吗？

实际上，唯一一次真正困扰我的时间是在调试时，并注释掉了bar（）：

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

除此之外，我倾向于使用：

if(foo) bar();

可以解决上述情况。

编辑感谢您澄清这个问题，我同意，我们不应该将代码写到最低公分母。

阅读速度...

除了已经提到的内容。至此，我已经习惯于分析带有花括号和空格的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(foo()) bar();

如果足够长，可以分成两行，请使用花括号。

我还曾经认为最好在真正需要时才使用花括号。但现在不再是这样，主要原因是，当您拥有大量代码时，它确实使它更具可读性，并且当您具有一致的支撑样式时，可以更快地解析代码。

除了在if中添加第二条语句的人之外，始终使用花括号的另一个好理由是可能发生以下情况：

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

您是否注意到else子句实际上是“ if（b）”的子句？您可能做到了，但是您相信任何人都可以熟悉此陷阱吗？

因此，如果只是为了保持一致性，并且因为您永远不知道当其他人（通常是其他愚蠢的人）更改代码时会发生什么意外情况，我总会花括号，因为这会使源代码更易读，并且解析起来更快。你的脑。仅对于最简单的if语句（例如，在哪里进行委派或类似于switch的情况），您知道该子句永远不会扩展的情况，我将省略括号。

这并不总是被认为是不好的做法。在Mono项目编码准则建议不要使用大括号，如果它是没有必要的。同为GNU编码标准。我认为与编码标准一样，这都是个人喜好问题。

线路便宜。处理器功能便宜。开发人员时间非常昂贵。

通常，除非我开发一些绝对对资源/速度有严格要求的应用程序，否则我总是会在编写代码时犯错

（a）任何其他开发人员都可以轻松了解我在做什么

（b）注释可能需要的特定代码部分

（c）如果出现问题，易于调试

（d）如果将来需要的话，很容易修改（即添加/删除代码）

从业务的角度来看，代码的速度或学术上的优雅是这些因素的次要因素。这并不是说我开始编写笨拙或丑陋的代码，但这是我的优先顺序。

通过在大多数情况下省略花括号，对我来说，这会使（b），（c）和（d）更加困难（但请注意，并非没有可能）。我会说是否使用花括号对（a）无效。

我更喜欢大括号提供的清晰度。您确切地知道这是什么意思，而不必猜测是否有人只是愚弄了他们并留下了他们（并引入了一个错误）。我唯一的遗漏是将if和action放在同一行上。我也不经常这样做。我实际上更喜欢通过将花括号放在自己的行上而引入的空格，尽管经过多年的类似K＆R C的编程，如果IDE不强制使用花括号结束行是我必须努力克服的一种做法。我。

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

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

我认为这取决于您正在从事的项目和个人喜好的准则。

我通常会在不需要它们时省略它们，但以下情况除外：

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 ++中出现此问题，但是由于这个原因，我不得不处理一些非常奇怪的错误。

我曾经以同样的方式思考。

直到一天（为什么总有一天会永远改变您的生活？），我们花了整整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 mb的日志，并要求我们停止它。调试标志还不够，因此必须进行搜索和替换println。

仍然当应用程序投入生产时，调试标志关闭，并且从未调用过重要的“ saveDayData”。

编辑

现在，唯一不使用花括号的地方是if / try构造。

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

看完超级巨星开发者之后。

我很高兴能够：

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 (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

与

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

非常令人困惑，所以我总是这样写：

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

只要有可能，我都会使用三元运算符，但绝不会 嵌套它们。

坦率地说，我将其视为：

优秀的程序员可以防御性地编程，劣质的程序员则不可以。

由于上面有几个示例，而我自己也有与忘记括号相关的错误的相似经历，因此我学会了始终使用括号的困难方法。

除了安全以外，其他任何事情都是选择个人风格，这显然是不好的编程方法。

乔尔甚至在使代码看起来不正确时提到了这一点

一旦由于缺少花括号而被bug咬住，您就会知道缺少花括号看起来是错误的，因为您知道它是另一个bug发生的潜在场所。

我同意“如果您足够聪明，可以让某人付钱给您编写代码，那么您应该足够聪明，不要仅仅依靠缩进来查看代码的流程。”

但是，可能会出错，这是调试的麻烦……尤其是当您要查看别人的代码时。

我的理念是，如果它使代码更具可读性，为什么不这样做呢？

显然，您必须在某些地方划界线，例如在简洁明了的变量名之间找到快乐的中介。但是方括号确实可以避免错误并提高代码的可读性。

您可以说，足够聪明的人可以成为编码员，他们将足够聪明，以避免引起无括号声明的错误。但是您能诚实地说您从未被拼写错误之类的简单事情绊倒吗？这样的Minutia在查看大型项目时可能会让人不知所措。

总是有例外，但是我反对仅在其中一种形式时才省略括号：

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

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

否则，我没有问题。

我偶尔会使用最底层的代码（多个using语句），但除此之外，我总是将花括号放进去。我只是发现它使代码更清晰。从不仅仅是缩进就可以明显看出，语句是块的一部分（因此可能是if等的一部分）。

我看过

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

臭虫咬我（或者更确切地说，“我和他的同事” -我其实没有引进的bug）一次。尽管事实上我们当时的编码标准建议在所有地方都使用花括号。我花了很长的时间才能发现-因为您看到了想要看到的东西。（大约是10年前。也许我现在发现它的速度更快。）

当然，如果您在行尾使用“花括号”，则可以减少多余的行数，但是我个人还是不喜欢这种样式。（我在工作中使用它，发现它不像我预期的那样令人讨厌，但是仍然有点不愉快。）

当您跳过单行代码中的大括号时，我对计算机编程领域的同行（您很多）印象深刻，并对此感到印象深刻。

我想这意味着我不聪明。我多次犯过这个错误。我已经解决了其他人的错误。因为这个原因，我已经看到软件附带了一些错误（RDP到运行VS2002的计算机上，并且您的监视窗口字体会变得很奇怪）。

如果我看一下我犯过的所有错误，这些错误可以通过更改编码样式来避免，那么清单很长。如果我在每种情况下都没有改变自己的方法，那么我可能永远不会成为程序员。再说一次，我想我并不聪明。为了弥补这一点，我长期以来一直是单行代码块上的括号的坚定用户。

也就是说，当今世界上发生了一些变化，这使得“您应在单行代码块上使用大括号”的规则如今比摩西将它带给我们时不再重要：

• 某些流行语言通过使计算机读取缩进来解决问题，就像程序员一样（例如Python）。

• 我的编辑器会自动为我设置格式，因此大大减少了因缩进而误导我的可能性。

• TDD意味着，如果由于单行代码块而使我感到困惑，那么我更有可能迅​​速发现该错误。

• 重构和语言表达能力意味着我的代码块要短得多，而单行代码块的发生频率要比过去更多。假设，如果无情地应用ExtractMethod，则整个程序中可能只有一行代码。（我想知道那会是什么样吗？）

实际上，无情地重构并在单行代码块上省去括号有一个明显的好处：当您看到括号时，您的头部会发出一个小警报，说“这里很复杂！当心！”。想象一下这是否是规范：

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

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

我的想法是将编码约定更改为“单行块可能永远都没有括号”或“如果您可以将块与条件放在同一行，并且都可以容纳80个字符，省略括号”。我们拭目以待。

在以下三个约定中：

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

和：

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

和（代表使用开括号和闭括号的任何缩进样式）：

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

我更喜欢最后一个：

• 如果所有的if语句都以统一的方式编写，我会更容易阅读。
• 它可能会使软件更加健壮并且没有错误。但是，所有现代IDE和高级文本编辑器都具有不错的自动缩进功能，我认为只要不破坏注释格式或不违反团队标准，每个人都应该使用（在很多情况下，可以创建自定义格式方案并与团队分享）。我的意思是，如果正确完成缩进，则引入错误的风险会有所降低。
• 我更喜欢布尔表达式和语句在不同的行执行。我希望能够将行标记为调试目的。即使我使用的IDE可以标记语句并逐步执行它，这也是一个交互式操作，并且我可能会忘记我在哪里开始调试，或者至少要花一些时间才能遍历几个代码。次（因为我必须在调试期间每次手动标记位置）。

反对使用花括号的主要论据是它们使用附加的行，并且需要附加的缩进。

行（几乎）是免费的，将代码中的行数减少到最小不是一个目标。

缩进与大括号用法无关。在您的级联“使用”示例中，我仍然认为即使省略括号也应缩进它们。

我坚信编写简洁的代码，但我总是会使用花括号。我发现它们是快速查看特定代码行存在范围的便捷方法。没有歧义，只是明确地摆在您面前。

有人可能会说这是优先选择的情况，但是我发现，如果程序的逻辑流程在内部是一致的，则容易遵循，并且我不认为编写这样的IF语句是一致的。

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

另一个像这样；

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

我更喜欢选择一种通用样式并坚持使用它：)

主要问题之一是当您具有一个衬里和一个不衬里的区域，以及与控制语句的分隔（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
}

我曾经是“花括号是必须的！”的大力支持者，但是自从采用单元测试以来，我发现我的单元测试可以防止无括号的语句免受以下情况的影响：

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

通过良好的单元测试，我可以放心地将花括号省略为简单的语句，以提高可读性（是的，这可能是主观的）。

另外，对于上述内容，我可能会将其内联为：

if (foo) snafu();

这样，需要在条件中添加bar（）的开发人员将更易于识别花括号的不足，并添加它们。

使用一些个人判断。

if (foo)
  bar();

本身就很好。除非您真的担心白痴以后再放入这样的东西：

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

如果您不担心白痴，那很好（我不是-如果他们不能正确使用基本代码语法，那么这是他们问题中最少的）>

作为交换，它更具可读性。

其余时间：

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

只要我记得，这就是我的最爱。另外：

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

为我工作。

垂直空间本身并不十分相关，但可读性却很重要。一行上的左大括号本身只是停止了语法元素的对话，直到您的视线移到下一行为止。不是我喜欢的

好的，这是一个古老的问题，已经死了。我要补充一点。

首先，我只需要说“大括号”即可。它们只能帮助提高可读性，除非您正在编写汇编，否则优先级列表上的（对于您自己和他人！）可读性应该很高。始终不可读的代码始终会导致错误。如果发现花括号使代码占用太多空间，则您的方法可能太长。如果操作正确，大多数或所有方法都应适合一个屏幕高度，并且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.
}

为了使带有花括号的代码不占用大量空间，我使用《代码完整》一书中推荐的技术：

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

假设您有一些代码：

if (foo)
    bar();

然后其他人出现并添加：

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

根据其编写方式，bar（）; 现在无条件执行。通过包括花括号，可以防止这种意外错误。代码的编写方式应使错误难以或不可能发生。如果我在进行代码审查时发现缺失的花括号，尤其是分布在多行中的花括号，则会造成缺陷。在合理的情况下，请将其放在一行上，以使发生这种错误的机会再次保持在最低水平。

减少行数并不是放括号的好理由。如果您的方法太大，则可能应该将其重构为较小的片段或进行重组。这样做无疑将比简单地取出括号来增加可读性。

我总是在适当的时候省略它们，例如您的第一个示例。一眼就能看到和理解的简洁代码比维护，调试和理解的代码要容易浏览，逐行阅读。我认为大多数程序员都会同意这一点。

如果您开始进行多个嵌套，if / else子句等等，很容易失控，但是我认为大多数程序员应该能够确定在哪里画线。

我认为这有点像if ( foo == 0 )vs 的论点if ( 0 == foo )。后者可以防止新程序员的错误（甚至对于退伍军人来说可能是偶然的），而前者在维护代码时更容易快速阅读和理解。

无论是公司还是FOSS项目，大多数时候它都是作为编码标准而根深蒂固的。

最终，其他人将需要使用您的代码，这对于每个开发人员来说都要弄清楚他们正在处理的代码部分的特定样式是一个主要的时间浪费。

另外，假设某人一天不止一次地在Python和Cish语言之间切换...在Python中，缩进是该语言的块代名词的一部分，并且像引用的错误一样容易犯错。

更安全的一面是错误-只有一个潜在的错误可能不需要修复。

如果我所有的纸巾都卷成卷，我个人会感到更加安全。即使对于单行代码，这些都是简单的符号，很容易防止出错。从某种意义上说，您可以清楚地看到块中的内容，以免使块的主体与该块之外的以下语句混淆，从而使代码更具可读性。

如果我有一个内衬，通常将其格式化为：

if( some_condition ) { do_some_operation; }

如果该行太麻烦了，请使用以下命令：

if( some_condition )
{
    do_some_operation;
}