blocks|key|358276|text|假设你有一些代码：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358277|if+(foo)
++++bar();|code-block|syntax|javascript|358278|然后另一个人走过来，补充道：|358279|if+(foo)
++++snafu();
++++bar();|358280|根据它的编写方式，现在可以无条件地执行bar()；。通过包含大括号，您可以防止这种意外错误。代码应该以这样的方式编写，以使此类错误难以或不可能犯。如果我正在做代码审查，看到缺少的大括号，特别是分布在多行上，我会创建一个缺陷。在有理由的情况下，将其保持在一行上，以便再次将犯此类错误的可能性保持在最低限度。|358281|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Let's say you have some code:

<pre><code>if (foo)
 bar();
</code></pre>

and then someone else comes along and adds:

<pre><code>if (foo)
 snafu();
 bar();
</code></pre>

According to the way it's written, bar(); is now executed unconditionally. By including the curly braces, you prevent this kind of accidental error. Code should be written in such a way as to make such mistakes difficult or impossible to make. If I was doing a code review and saw the missing braces, especially spread across multiple lines, I would create a defect. In cases where it is justified, keep it on one line so that the chance of making such an error is again kept to a minimum.

blocks|key|355695|text|如果您的维护程序员在应用程序中添加了逻辑，那么他/她可能会忘记添加大括号。因此，会发生以下情况：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355696|if(foo)
bar();
bar(delete);|code-block|syntax|javascript|355697|而不是|355698|if(foo)+{
bar();
}
+bar(delete);|355699|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Your maintanence programmer may forget to add curly braces later if he/she adds logic to the app. So the following happens:

<pre><code>if(foo)
bar();
bar(delete);
</code></pre>

Instead of

<pre><code>if(foo) {
bar();
}
 bar(delete);
</code></pre>

blocks|key|358315|text|总是有例外的，但我反对只在其中一种形式中省略大括号：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358316|358317|+if(x+==+y)+for(/*+loop+*/)+{+//200行}//rampion的例子:+for(/*+loop+*/)+{+for(/*+loop+*/)+for(/*+loop+*/)+{//几行}}|blockquote|358318|358319|358320|否则，我对它没有任何问题。|358321|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|N|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|K|$]]

There are always exceptions, but I would argue against omitting braces only when it's in one of the forms:

<blockquote>
<pre><code>if(x == y)
 for(/* loop */)
 {
 //200 lines
 }

//rampion's example:
for(/* loop */)
{
 for(/* loop */)
 for(/* loop */)
 {
 //several lines
 }
}
</code></pre>
</blockquote>

Otherwise, I have no problem with it.

blocks|key|355709|text|实际上，唯一让我感到头疼的是我在调试的时候，并且注释掉了bar()：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355710|if(foo)
++//+bar();
doSomethingElse();|code-block|syntax|javascript|355711|除此之外，我倾向于使用：|355712|if(foo)+bar();|355713|它负责处理上面的情况。|355714|EDIT谢谢你澄清了这个问题，我同意，我们不应该写最小公分母的代码。|offset|length|style|BOLD|355715|entityMap^0|0|0|0|0|0|0|4|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@$O|10|P|11|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Actually, the only time that's ever really bit me was when I was debugging, and commented out bar():

<pre><code>if(foo)
 // bar();
doSomethingElse();
</code></pre>

Other than that, I tend to use:

<pre><code>if(foo) bar();
</code></pre>

Which takes care of the above case.

EDIT Thanks for clarifying the question, I agree, we should not write code to the lowest common denominator.

blocks|key|355717|text|我偶尔会使用最底层的代码(多个using语句)，但除此之外，我总是把大括号放在里面。我只是发现它让代码更清晰。从不仅仅是缩进可以明显看出，语句是块的一部分(因此很可能是if等的一部分)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355718|我已经看过|355719|if+(...)
++++foo();
++++bar();|code-block|syntax|javascript|355720|虫子咬了我一次(或者更确切地说是“我和同事们”--我实际上并没有引入这个虫子)。尽管我们当时的编码标准建议到处使用大括号，但这仍然是事实。我花了令人惊讶的长时间才发现--因为你看到了你想看到的东西。(这是大约10年前的事了。也许我现在会更快地找到它。)|355721|当然，如果你使用“行尾的花括号”，它会减少额外的行数，但我个人不喜欢这种风格。(我在工作中使用它，我发现它没有我想象的那么令人不快，但它仍然有点不舒服。)|355722|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I occasionally use the very bottom code (multiple using statements), but other than that I always put the braces in. I just find it makes the code clearer. It's blatantly obvious from more than just indentation that a statement is part of a block (and thus probably part of an if etc).

I have seen the

<pre><code>if (...)
 foo();
 bar();
</code></pre>

bug bite me (or rather "me and colleagues" - I didn't actually introduce the bug) once. This was despite the fact that our coding standards at the time recommended using braces everywhere. It took me a surprisingly long time to spot - because you see what you want to see. (This was about 10 years ago. Maybe I'd find it faster now.)

Of course if you use "brace at the end of the line" it reduces the extra lines incurred, but I personally dislike that style anyway. (I use it at work, and have found it less unpleasant than I expected, but it's still a bit unpleasant.)

blocks|key|3139351|text|大多数时候，它是一个根深蒂固的编码标准，无论是对于一个公司还是一个自由/开源软件项目。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139352|最终，其他人将需要摸索您的代码，这是每个开发人员必须弄清楚他们正在工作的代码部分的特定样式的主要时间消耗。|3139353|另外，假设某人每天在Python和Cish语言之间来回切换不止一次……在Python中，缩进是语言的块语法的一部分，很容易犯像你引用的那样的错误。|3139354|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Most times it is ingrained as a coding standard, whether for a company or an FOSS project.

Ultimately someone else will need to grok your code and it is a major time drain for each developer to have to figure out the specific style of the section of code they are working on.

Also, imagine that someone is going between Python and a Cish language more than once a day... In Python indenting is part of the block symantics of the language and it would be quite easy to make a mistake like the one you quote.

blocks|key|358326|text|其中一个主要问题是，当您有一行程序和非一行程序的区域时，以及与控制语句(for、if等)的分离以及语句的结尾。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|358327|例如：|358328|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
}|code-block|syntax|javascript|358329|entityMap^0|10|3|14|2|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|U|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

One of the main issues is when you have regions of one-liners and non-one liners, 
along with separation from the control statment (<code>for</code>, <code>if</code>, what have you) and the end of the statment.

For example:

<pre><code>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
}
</code></pre>

blocks|key|3352139|text|我同意“如果你足够聪明，让别人付钱让你写代码，你就应该足够聪明，不能仅仅依靠缩进来查看代码的流程。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352140|然而..。错误是可以犯的，这一点调试起来很痛苦……尤其是当你要查看别人的代码时。|3352141|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I agree that "if you are smart enough to get someone to pay you to write code, you should be smart enough to not rely solely on indentation to see the flow of the code."

However... mistakes can be made, and this one is a pain to debug... especially if you're coming in looking at someone else's code.

blocks|key|358335|text|它是更短的代码(更好的可读性)与更安全的代码(更不容易出错)的折衷。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358336|我的2点看法：|358337|358338|这条规则是有原因的。它是由无数的程序员在漫长的工作时间里开发出来的，直到深夜或第二天早上，试图修复一个由小疏忽引起的错误。|ordered-list-item|358339|你必须自己决定这个交易是否值得。|358340|在我的经验中，我是无数程序员中的一员，他们工作到深夜才找到一个令人讨厌的错误的原因。|358341|。原因是我太懒了。|358342|358343|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

It is a tradeof, shorter code (better readable) versus more secure code (less error prone).

My 2 cents:

<ol>
<li>There is a reason for this rule. It has been developed by countless programmers through long working hours, stretching into the night or next morning, trying to fix a bug that was caused by a little oversight.</li>
<li>You have t decide for yourself if the tradeof is worth it.</li>
<li>In my experience it is, I am one of those countless programmers who was working into the night to find the cause for a nasty bug. The cause was me being lazy.</li>
</ol>

blocks|key|355740|text|为了避免带大括号的代码占用大量空间，我使用了Code+Complete一书中推荐的技术|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|355741|if+(...)+{
++++foo();
++++bar();
}
else+{
++++...
}|code-block|syntax|javascript|355742|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cc2e.com/Default.aspx^0|M|D|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

in order to keep the code with braces from taking up lots of space, I use the technique recommended in the book <a href="http://www.cc2e.com/Default.aspx" rel="noreferrer" title="Code Complete">Code Complete</a>:

<pre><code>if (...) {
 foo();
 bar();
}
else {
 ...
}
</code></pre>

blocks|key|354991|text|我总是在适当的时候省略它们，比如在您的第一个示例中。看一眼就能看到和理解的干净、简洁的代码比我必须逐行滚动阅读的代码更容易维护、调试和理解。我认为大多数程序员都会同意这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|354992|如果你开始做多个嵌套，if/else子句等等，它很容易失控，但我认为大多数程序员应该能够知道该在哪里划清界限。|354993|我认为这有点像if+(+foo+==+0+)和if+(+0+==+foo+)的争论。后者可以防止新程序员的bug(甚至可能偶尔会防止老程序员)，而前者在维护代码时更容易快速阅读和理解。|offset|length|style|CODE|354994|entityMap^0|0|0|7|F|N|F|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]|$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

I always omit them when appropriate, such as in your first example. Clean, concise code I can see and understand by glancing at is easier to maintain, debug and understand than code I have to scroll through and read line by line. I think most programmers will agree with this. 

It is easy for it to get out of hand if you start doing multiple nesting, if/else clauses and so on, but I think most programmers should be able to tell where to draw the line.

I see it kind of like the argument for <code>if ( foo == 0 )</code> vs <code>if ( 0 == foo )</code>. The latter may prevent bugs for new programmers (and maybe even occasionally for veterans), while the former is easier to quickly read and understand when you're maintaining code.

blocks|key|358357|text|你反对使用大括号的主要理由是它们使用了额外的行，并且它们需要额外的缩进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358358|行(几乎)是免费的，最小化代码中的行数不应该是一个目标。|358359|并且缩进与大括号的使用无关。在你的级联'using‘例子中，我仍然认为你应该缩进它们，即使你省略了大括号。|358360|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Your main arguments against using braces are that they use additional lines and that they require additional indenting.

Lines are (almost) free, minimizing the number of lines in your code shouldn't be an objective.

And indentation is independent of brace usage. In your cascading 'using' example I still think you should be indenting them even when you omit the braces.

blocks|key|3352206|text|我曾经是“花括号是必须的！”的坚定支持者，但自从采用单元测试以来，我发现我的单元测试可以保护无括号语句不受以下场景的影响：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352207|if+(foo)
++++snafu();
++++bar();|code-block|syntax|javascript|3352208|有了好的单元测试，我可以自信地省略简单语句的大括号，以提高可读性(是的，这可能是主观的)。|3352209|或者，对于类似上面的内容，我可能会将其内联为：|3352210|if+(foo)+snafu();|3352211|这样，需要将bar()添加到条件中的开发人员将更容易认识到缺少大括号，并添加它们。|3352212|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|U|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I used to be a huge supporter of "curly braces are a MUST!", but since adopting unit testing, I find that my unit tests protect braceless statements from the scenarios like:

<pre><code>if (foo)
 snafu();
 bar();
</code></pre>

With good unit tests, I can confidently omit curly braces for simple statements to improve readability (yes, that can be subjective).

Alternatively, for something like the above, I would likely inline that to look like:

<pre><code>if (foo) snafu();
</code></pre>

That way, the developer who needs to add bar() to the condition, would be more apt to recognize the lack of curly braces, and add them.

blocks|key|3352214|text|如果是小的东西，就写成这样：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352215|if(foo())+bar();|code-block|syntax|javascript|3352216|如果它足够长，可以分成两行，使用大括号。|3352217|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

If it's something small, write it like this:

<pre><code>if(foo()) bar();</code></pre>

If it's long enough to break into two lines, use braces.

blocks|key|3352219|text|我更喜欢花括号提供的清晰度。你确切地知道这是什么意思，不需要去猜测是不是有人犯了错而忽略了它们(并引入了一个bug)。我唯一省略它们的时候是把if和action放在同一行的时候。我也不经常这样做。实际上，我更喜欢通过将大括号放在自己的行上来引入空格，尽管从多年的K&R+C类编程经验来看，如果IDE不为我强制执行，我必须努力克服以大括号结束一行的做法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352220|if+(condition)+action();++//+ok+by+me

if+(condition)+//+normal/standard+for+me
{
+++action();
}|code-block|syntax|javascript|3352221|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I prefer the clarity that the curly brace offers. You know exactly what is meant and don't have to guess if someone just goofed and left them off (and introduced a bug). The only time I omit them is when I put the if and action on the same line. I don't do that very often either. I actually prefer the whitespace introduced by putting the curly brace on its own line, though from years of K&amp;R C-like programming, ending the line with a brace is a practice I have to work to overcome if the IDE doesn't enforce it for me.

<pre><code>if (condition) action(); // ok by me

if (condition) // normal/standard for me
{
 action();
}
</code></pre>

blocks|key|355003|text|我的哲学是，如果它使代码更具可读性，为什么不这样做呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355004|显然，你必须在某个地方划清界限，比如在简明和过度描述性的变量名之间找到一个令人满意的中间点。但是括号确实避免了错误，提高了代码的可读性。|355005|你可以争辩说，聪明到足以成为程序员的人将足够聪明，以避免导致无括号语句的错误。但老实说，你从来没有被像拼写错误这样简单的事情绊倒过吗？在查看大型项目时，像这样的细枝末节可能会让人不知所措。|355006|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

My philosophy is if it makes the code more readable, why not do it?

Obviously you have to draw the line somewhere, like finding that happy medium between concise and overly descriptive variable names. But brackets really do avoid errors and improve the readability of the code.

You can argue that people smart enough to be coders are going to be smart enough to avoid bugs that stem bracketless statements. But can you honestly say you've never been tripped up by something as simple as a spelling error? Minutia like this can be overwhelming when looking at large projects.

blocks|key|355791|text|​|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355792|355793|将左方括号写在与上一条语句相同的行上：|unordered-list-item|355794|355795|if+(+any+){+DoSomething()；}|355796|355797|如果你觉得这太大了，你可以把它写成一行：|355798|355799|if+(+any+){+DoSomething()；}|355800|如果你认为，在一行中读起来不是那么好，你可以写成两行：|355801|if+(+any+){+DoSomething()；}+if+(+any+){+DoSomething()；}|355802|355803|将来有人需要将一条语句更改为多条语句。没有括号的变化会更复杂。是的，只有一点点，但更好的是防止bug。编写括号非常简单，而且成本很低。|355804|355805|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|14|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1A|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|X|$]]

<li> Write the opened bracket on the same line as previous statement:

<pre><code>if ( any ) {
 DoSomething();
}
</code></pre>

<li> If you think, this is too big, you
 can write it in one line:

<pre><code>if ( any ) { DoSomething(); }
</code></pre>

If you think, in one line is not readable so good, you can write it in two lines:

<pre><code>if ( any ) {
 DoSomething(); }
if ( any )
 { DoSomething(); }
</code></pre>

<ul>
<li>In future someone will need change
one statement to more statements.
Without brackets is the change more
complicated. Yes only littlebit, but
is better prevent bugs. And writing
brackets is very easy a cheap way.</li>
</ul>

blocks|key|3139450|text|这并不总是被认为是一种糟糕的做法。Mono+Project+Coding+Guidelines建议在不必要的情况下不要使用大括号。GNU+Coding+Standards也是如此。我认为这是个人喜好的问题，一如既往的编码标准。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3139451|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mono-project.com/Coding_Guidelines|1|http://www.gnu.org/prep/standards/standards.html^0|H|U|0|1T|K|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

This is not always considered a bad practice. The <a href="http://www.mono-project.com/Coding_Guidelines" rel="noreferrer">Mono Project Coding Guidelines</a> suggests not to use curly braces if it's not necessary. The same for the <a href="http://www.gnu.org/prep/standards/standards.html" rel="noreferrer">GNU Coding Standards</a>. I think it's a matter of personal taste as always with coding standards.

blocks|key|355010|text|我不认为省略大括号总是一个糟糕的做法，但是否应该被允许，以及在什么情况下必须在团队中达成一致。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355011|我发现这是非常可读性的：|355012|if+(foo)
++++bar();|code-block|syntax|javascript|355013|这是：-|355014|if+(foo)
++++bar()
else
++++snafu();|355015|如果在这些代码中添加额外的一行：-|355016|if+(foo)
++++bar();
++++snafu();|355017|这看起来全错了，有一段缩进的代码。但没有做好准备。|355018|类似的论点也适用于for循环。然而，当我开始嵌套时：|355019|if+(foo)
++++if+(bar)
++++++++snafu()|355020|现在我遇到了麻烦，它看起来像一块语句。就我个人而言，我只会跳过一个级别的大括号的使用，只会让外部代码使用大括号：|355021|if+(foo)+{
+++if+(bar)
+++++++snafu()
}|355022|当我输入这篇文章时，我看到答案从1跳到了17，显然这将是一个情绪化的问题(我建议你在标签列表中添加主观(我做这件事的能力已经丢失了，这是怎么回事？)。|355023|最重要的是在团队中就是否可以接受以及如何接受达成一致，并坚持下去。|355024|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|19|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1C|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|1F|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|F|7|1H|8|@]|9|@]|A|$G|H]]|$1|10|3|11|5|6|7|1I|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1J|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|15|$]]

I don't think that omitting braces is always a bad practice but whether is should be allowed and under what circumstances must be agreed in the team.

I find this very readable:-

<pre><code>if (foo)
 bar();
</code></pre>

and this:-

<pre><code>if (foo)
 bar()
else
 snafu();
</code></pre>

If an extra line is added to these:-

<pre><code>if (foo)
 bar();
 snafu();
</code></pre>

This looks all wrong, there is a block of code, indented. but not braced.

A similar argument holds for a for loop. However when I start nesting:-

<pre><code>if (foo)
 if (bar)
 snafu()
</code></pre>

Now I'm running into trouble, it looks like a block of statements. Personally I would only skip the use of braces for one level only any deeper an I'd make the outer code use braces:-

<pre><code>if (foo) {
 if (bar)
 snafu()
}
</code></pre>

As I'm typing this I've seen the answers jump from 1 to 17, clearly this going to be an emotive question (I suggest you add subjective to the tag list (my ability to do this has gone missing whats up with that?)).

The most important thing is to have agreement in the team as to if and how its acceptable and stick with it.

blocks|key|355026|text|AFAIR大括号始终是一个作用域，因此每次都使用它们是很好的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355027|不带大括号：|355028|if(DoSomething)
++++MyClass+myClass+=+new+MyClass();

myClass.DoAnythingElse();|code-block|syntax|javascript|355029|这将进行编译，但很容易导致空引用。(C#编译器不会对此进行编译，这是件好事！)|355030|而这样的话：|355031|if(doSomething)
{
++++MyClass+myClass+=+new+MyClass();
}

myClass.DoAnythingElse();|355032|甚至不会编译。|355033|这比在编译时缩小异常要好得多，也比在运行时发现异常要好得多。|355034|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|Z|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

AFAIR curly braces are always a scope, so for that it is good to use them everytime.

Without the braces:

<pre><code>if(DoSomething)
 MyClass myClass = new MyClass();

myClass.DoAnythingElse();
</code></pre>

This will compile, but lead to null references easily. (C# compiler does not compile this, good thing!)

Whereas this way:

<pre><code>if(doSomething)
{
 MyClass myClass = new MyClass();
}

myClass.DoAnythingElse();
</code></pre>

won't even compile.

It is far better than minize Exceptions at compiletime already, than finding them at runtime.

blocks|key|3352260|text|我认为这是你正在工作的项目的指导方针和个人品味的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352261|我通常会在不需要它们的时候省略它们，除了下面这样的一些情况：|3352262|if+(something)
++++just+one+statement;+//+i+find+this+ugly
else
{
++++//+many
++++//+lines
++++//+of+code
}|code-block|syntax|javascript|3352263|我更喜欢|3352264|if+(something)
{
++++just+one+statement;+//+looks+better:)
}
else
{
++++//+many
++++//+lines
++++//+of+code
}|3352265|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I think it's a matter of guidelines for the project you are working on and personal taste.

I usually omit them when they are not needed, except some cases like the following:

<pre><code>if (something)
 just one statement; // i find this ugly
else
{
 // many
 // lines
 // of code
}
</code></pre>

i prefer

<pre><code>if (something)
{
 just one statement; // looks better:)
}
else
{
 // many
 // lines
 // of code
}
</code></pre>

blocks|key|3352267|text|其中一个例子就是回到C/C%2B%2B宏的旧时代。我知道这是一个C#问题，但编码标准通常会在没有最初创建标准的原因的情况下继续存在。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352268|如果在创建宏时不小心，最终可能会导致不使用{}的If语句出现问题。|3352269|#define+BADLY_MADE_MACRO(x)+function1(x);+function2(x);

if+(myCondition)+BADLY_MADE_MACRO(myValue)|code-block|syntax|javascript|3352270|现在，不要误会我的意思，我并不是说在C/C%2B%2B中为了避免这个问题，你应该总是这样做，但是我不得不处理一些非常奇怪的but。|3352271|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

One of the instances where this can bite you is back in the old days of C/C++ macros. I know this is a C# question, but often coding standards carry over without the reasons why the standard was created in the first place.

If you aren't very careful when you create your macros, you can end up causing problems with if statements that don't use the {}.

<pre><code>#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)
</code></pre>

Now, don't get me wrong, I'm not saying that you should always do {} just to avoid this problem in C/C++, but I have had to deal with some very strange bugs because of this.

blocks|key|355041|text|在更安全的方面出错--只是再多一个你可能不需要修复的bug。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355042|就我个人而言，如果我所有的积木都被curlys包裹起来，我会感到更安全。即使对于一行程序，这些都是简单的符号，可以很容易地防止错误。它使代码更具可读性，因为您可以清楚地看到块中的内容，这样就不会将块的主体与块外的以下语句混淆。|355043|如果我有一行代码，我通常会将其格式化为：|355044|if(+some_condition+)+{+do_some_operation;+}|code-block|syntax|javascript|355045|如果这行代码太繁琐，那么可以使用以下代码：|355046|if(+some_condition+)
{
++++do_some_operation;
}|355047|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|T|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Err on the side of more secure - just one more bug you potentially won't have to fix.

I personally feel more secure if all of my blocks are wrapped in curlys. Even for one-liners, these are simple notations that easily prevent mistakes. It makes the code more readable in the sense that you clearly see what is in the block as not to confuse the body of the block with the following statements outside of the block.

If I have a one-liner, I typically format it as follows:

<pre><code>if( some_condition ) { do_some_operation; }
</code></pre>

If the line is just too cumbersome then use the following:

<pre><code>if( some_condition )
{
 do_some_operation;
}
</code></pre>

blocks|key|3139529|text|好吧，在我看来，这更多的是我个人的喜好。然而，我注意到，为了可读性，有{}比没有它们更好。我注意到在使用ReSharper时，ReSharper倾向于删除它们，并且执行大多数if语句，例如|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139530|if(this+==+yes)
++++++DoSomething();|code-block|syntax|javascript|3139531|但是为了可读性，我总是这样做。|3139532|if(this+==+yes)
{
+DoSomething();
}|3139533|虽然"+if“语句中只有一行代码，但可读性并没有真正的不同，但如果你在一个if语句中放入20-30行代码，那么使用{}会更容易阅读，并且在代码中留下更少的错误和bug的空间。|3139534|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Ok it has always seemed to me that this is more of personal preference to me. I have noticed however for readability it is better to have { } then to not have them. I have notice using ReSharper that ReSharper tends to delete them and do most of you if statements like this

<pre><code>if(this == yes)
 DoSomething();
</code></pre>

But for readability sake I always do

<pre><code>if(this == yes)
{
 DoSomething();
}
</code></pre>

Although with only one line of code in the "if" statement readability isnt really different but if you put 20-30 lines of code in one if statement then it is easier to read with the {} there and it leaves less room for error and bugs in your code.

blocks|key|3139552|text|我也曾经认为，只有在真正需要的时候才使用大括号会更好。但现在不再是这样了，主要原因是，当你有很多代码时，它确实使代码更具可读性，并且当你有一致的大括号样式时，你可以更快地解析代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139553|除了有人在if中添加第二个语句之外，总是使用大括号的另一个很好的原因是，可能会发生这样的事情：|3139554|if(a)
+++if(b)
+++++c();
else
+++d();|code-block|syntax|javascript|3139555|您是否注意到else子句实际上是"if(b)“的子句？你可能是这样做的，但你相信任何人都熟悉这一点吗？|3139556|所以，如果只是为了一致性，并且因为你永远不知道当其他人(总是其他愚蠢的人)更改代码时会发生什么意想不到的事情，我总是放大括号，因为它使源代码更具可读性，更快地被你的大脑解析。只有一些最简单的if语句，比如if，其中进行了委托或类似于switch，您知道子句永远不会被扩展，我会省略大括号。|3139557|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I also used to think it's better to only use braces when really needed. But not anymore, the main reason, when you have a lot of code, it does make it more readable and you can parse over the code quicker when you have a consistent bracing style.

Another good reason for always using braces, besides someone adding a second statement to the if, is something like this could happen:

<pre><code>if(a)
 if(b)
 c();
else
 d();
</code></pre>

Did you notice that the else clause is actually that of the "if(b)"? You probably did, but would you trust anyone to be familiar with this gotcha?

So, if just for consistency and because you never know what unexpected things might happen when someone else (it's always the others that are stupid) changes the code, I always put braces, because it makes the source code more readable, quicker to parse by your brain. Only for the most simple if statements, like an if where a delegation is made or is switch-like, where you know the clause will never be extended, I would leave out the braces.

blocks|key|3352314|text|您是否考虑过在单行if+else语句中使用此选项：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352315|(!a)+?+Foo()+:+Bar();|code-block|syntax|javascript|3352316|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Have you thought about exploring this option for single line if else statement:

<pre><code>(!a) ? Foo() : Bar();
</code></pre>

blocks|key|358428|text|我坚信编写简洁整洁的代码，但我总是使用大括号。我发现它们是一种快速查看特定代码行所在范围的便捷方法。没有歧义，它只是明确地摆在你面前。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358429|有些人可能会说这是偏好的情况，但我发现如果一个程序的逻辑流程是内部一致的，那么它就更容易遵循，而且我不相信像这样写一个if语句是一致的；|358430|if(x+<+y)
++++x+=+y;
else
++++y+=+x;|code-block|syntax|javascript|358431|和另一个像这样的；|358432|if(x+<+y)
{
++++x+=+y;
++++x%2B%2B;
}
else
{
++++y+=+x;
++++y%2B%2B;
}|358433|我更喜欢选择一种通用的风格，并坚持下去:)|358434|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I'm a strong believer in writing tidy and concise code, but I would always use curly braces. I find that they are a convenient way of quickly seeing the scope in which a particular line of code exists. There is no ambiguity, it's just explicitly set out in front of you.

Some may say it is a case of preference, but I find the logical flow of a program much easier to follow if it is internally consistent, and I don't believe that it is consistent to write one IF statement like this;

<pre><code>if(x &lt; y)
 x = y;
else
 y = x;
</code></pre>

And another like this;

<pre><code>if(x &lt; y)
{
 x = y;
 x++;
}
else
{
 y = x;
 y++;
}
</code></pre>

I prefer to just pick one general style and stick with it :)

blocks|key|355914|text|当我看到“这种风格节省空间”时，我总是感到困惑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355915|因为我很少打印出代码，所以获得空间对我来说没有明显的好处:在磁盘上节省一些字节是不值得的，我也不会为屏幕上占用的空间付费。|355916|有些人觉得紧凑的代码更具可读性，我不会否认这一点(非常主观)，但作为业余艺术家和排版专家，我高度重视空格的使用……|355917|我不会重复上面的论点，但我会补充，我认为，一致性:我不喜欢像这样的代码|355918|if+(foo)
{
++//+Lot+of+code
}
else
++DoStuff();|code-block|syntax|javascript|355919|话虽如此，有时我沉迷于没有花括号:在守卫条件下，当我提前退出时：|355920|if+(somethingBadHappened)
++return;|355921|总而言之，我认为(几乎)系统地在重要代码周围添加大括号可以提高可读性(代码“呼吸”，不会受到限制)，一致性，并可能避免一些愚蠢的错误(是的，这种错误是显而易见的，但程序员(通常)是人，可能很累，新手，在压力下...)。|355922|我已经为SciTE做了一个Lua宏，只需一次击键和正确的缩进，就可以在任何代码块或当前行周围添加这些花括号:对我来说，这真的不需要任何成本。|355923|现在，如果你选择省略这些支架，我不会起诉你。正如其他人指出的那样，可以在编码规则中设置一个或另一个选项。各自为政。|355924|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

I am always perplex when I see "this style saves space". 
Since I rarely, if ever, print out code, gain of space has no obvious advantage for me: saving some bytes on disk doesn't worth it, and I don't pay for space taken on screen. 
Some people find compact code more readable, I won't argue no this (highly subjective), but as amateur artist and typograph, I highly value whitespace use...

I won't repeat the above arguments, but I will add, I think, consistency: I dislike code like

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

Having said that, sometime I indulge in no braces: in guard conditions, when I do early exit:

<pre><code>if (somethingBadHappened)
 return;
</code></pre>

To summarize, I think adding (almost) systematically braces around significant code improves readability (code "breathes", isn't cramped), consistency, and might avoid some stupid mistakes (yes, this kind of error is obvious, but coder is human (in general), can be tired, newbie, under stress...).

I have made a Lua macro for SciTE to add these braces around any block of code or current line, with one keystroke and correct indentation: it really costs nothing for me.

Now, I won't sue you if you chose to omit these braces. As others point out, one option or the other can be set in coding rules. To each their owns.

blocks|key|358448|text|减少行数并不是一个很好的去掉大括号的理由。如果你的方法太大了，可能应该把它重构成更小的片段或者进行重构。这样做无疑会增加可读性，而不仅仅是去掉大括号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358449|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Reducing lines is not really a good argument for dropping braces. If your method is too big, it should probably be refactored into smaller pieces or restructured. Doing that will no doubt increase readability more than simply taking out braces.

blocks|key|3139616|text|线路很便宜。处理器的功耗很便宜。开发人员的时间非常昂贵。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139617|一般来说，除非我正在开发一些对资源/速度有绝对要求的应用程序，否则我在编写代码时总是会犯错误。|3139618|(a)任何其他开发人员都很容易遵循我正在做的事情|3139619|(b)注释代码中可能需要它的特定部分|3139620|(c)如果出现问题，易于调试|3139621|(d)如果将来需要，易于修改(例如，添加/删除代码)|3139622|从商业的角度来看，代码的速度或学术优雅是次要的。这并不是说我开始编写笨拙或丑陋的代码，但这是我的优先顺序。|3139623|由于在大多数情况下省略了大括号，这对我来说使(b)、(c)和(d)变得更加困难(注意并非不可能)。我要说的是，是否使用大括号对(a)没有影响。|3139624|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

Lines are cheap. Processor power is cheap. Developer time is very expensive.

As a general rule, unless I am developing some absolutely resource / speed critical application, I would always err on the side of writing code that is

(a) Easy for any other developer to follow what I am doing

(b) Comment specific parts of the code that may need it

(c) Easy to debug if something goes wrong

(d) Easy to modify if it needs to be in future (i.e. adding / removing code)

The speed or academic elegance of the code is secondary to these factors from a Business perspective. This is not to say I set out to write clunky or ugly code, but this is MY order of priority.

By omitting curly braces in most instances, it for me makes (b), (c) and (d) more difficult (note not impossible however). I would say that using curly braces or not has not effect on (a).

blocks|key|355935|text|一方面，我省略了大括号中的一条语句。另一方面，我使用PC-Lint+(http://www.gimpel.com/)检查所有C代码，它将if()语句后面的两个或更多缩进行标记为“可疑缩进”。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|355936|顺便说一下，将单个语句与if()放在同一行看起来是个好主意。|355937|entityMap|0|LINK|mutability|MUTABLE|url|http://www.gimpel.com/^0|Z|M|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

On the one hand, I leave the braces out for a single statement. On the other hand, I check all C code with PC-Lint (<a href="http://www.gimpel.com/" rel="nofollow noreferrer">http://www.gimpel.com/</a>), which flags two or more indented lines following an if() statement as "suspicious indentation".

By the way, putting single statements on the same line as the if() looks like a good idea.

blocks|key|358477|text|令我印象深刻和谦卑的是，我在计算机编程领域的同行(你们很多人)并没有被当你跳过单行代码块上的花括号时潜在的bug的前景吓倒。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358478|我想这意味着我不聪明。在这个问题上，我已经犯了很多次错误。我已经在这个问题上调试了别人的错误。我曾看到软件因此而发布错误(RDP到运行VS2002的机器上，你的手表窗口字体会变得摇摇欲坠)。|358479|如果我看一下我所犯的所有错误，这些错误本可以通过改变编码风格来避免的，那么这个列表是非常长的。如果我没有在这些情况下改变我的方法，我可能永远不会成为一名程序员。再说一次，我想我并不聪明。为了弥补这一点，我在很长一段时间里一直是单行代码块上大括号的忠实用户。|358480|也就是说，世界上的一些事情已经发生了变化，使得“你应该在单行代码块上使用大括号”规则在今天变得不那么重要了，而不是摩西把它带给我们的时候：|358481|358482|一些流行的语言通过让计算机读取缩进来解决这个问题，就像程序员一样(例如|unordered-list-item|358483|)。|358484|我的编辑器会自动为我格式化，所以我被缩进误导的可能性很大reduced.|offset|length|style|BOLD|358485|TDD意味着如果我因为被单行代码块弄糊涂而引入了一个bug，我更有可能很快发现这个bug。|358486|Refactoring和language+expressiveness意味着我的代码块要短得多，单行代码块的出现频率也比以前高得多。假设，使用无情的ExtractMethod应用程序，我的整个程序中可能只有单行代码块。(我想知道那会是什么样子？)|358487|358488|事实上，无情的重构有一个明显的好处&省略单行代码块上的大括号:当你看到大括号时，你的脑海中可能会响起一个小警报，说“这里很复杂！小心！”。想象一下，如果这是常态：|358489|if+(condition)+Foo();+++//+normal,+everyday+code

if+(condition)+
{
++++//+something+non-trivial+hapening;+pay+attention!
++++Foo();
++++Bar();
}|code-block|syntax|javascript|358490|我愿意改变我的编码习惯，比如“单行代码块可能永远不会有大括号”，或者“如果你可以把代码块放在与条件相同的一行上，并且都在80个字符以内，那么就省略大括号”。我们走着瞧。|358491|entityMap^0|0|0|0|0|0|0|0|5|8|0|0|3|0|0|Z|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1A|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1B|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1C|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|1E|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@]|A|$]]|$1|N|3|O|5|K|7|1G|8|@$P|1H|Q|1I|R|S]]|9|@]|A|$]]|$1|T|3|U|5|K|7|1J|8|@$P|1K|Q|1L|R|S]]|9|@]|A|$]]|$1|V|3|W|5|K|7|1M|8|@$P|1N|Q|1O|R|S]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|10|3|11|5|12|7|1R|8|@]|9|@]|A|$13|14]]|$1|15|3|16|5|6|7|1S|8|@]|9|@]|A|$]]|$1|17|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|18|$]]

I am impressed and humbled that my peers in this field of computer programming (you lot) are not daunted by the prospect of potential bugs when you skip the braces on single line blocks.

I suppose it means I'm not smart. I have made mistakes around this multiple times. I have debugged others' mistakes around this. I have watched software ship with bugs because of this (RDP to a machine running VS2002 and your watch window font will go wonky).

If I look at all the mistakes I've made that could have been avoided with a change in coding style, the list is very long. If I hadn't changed my approach in each of these cases, I probably would never have made it as a programmer. Again, I guess I'm not smart. To compensate, I have been a staunch user of braces on single-line blocks for a long time.

That said, some things have changed in the world that make the "thou shalt use braces on single-line blocks" rule less relevant today than when Moses brought it down to us:

<ul>
<li>Some popular languages make the issue go away by making the computer read the indentation, just like the programmer does (e.g. Python).</li>
<li>My editor automatically formats for me, so the chances of me getting mislead by indentation is much reduced.</li>
<li>TDD means that if I introduce a bug because I get confused by a single-line block, I'm much more likely to discover the bug quickly. </li>
<li>Refactoring and language expressiveness mean that my blocks are much shorter, and single-line blocks happen much more often than the used to. Hypothetically, with a ruthless application of ExtractMethod, I could possibly have only single-line blocks in my whole program. (I wonder what that would look like?)</li>
</ul>

In fact, there's a distinct benefit can come of refactoring ruthlessly &amp; omitting braces on single-line blocks: when you see braces, a little alarm can go off in your head that says "complexity here! beware!". Imagine if this was the norm:

<pre><code>if (condition) Foo(); // normal, everyday code

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

I'm opening myself to the idea of changing my coding convention to something like "single-line blocks may never have braces" or "if you can put the block on the same line as the condition, and it all fits within 80 characters, omit the braces". We'll see.

blocks|key|3139688|text|我总是使用大括号，除非在最里面的语句上，假设最里面的语句是单行的。所以我的代码看起来像这样：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139689|for+(int+i=0;+i<10;+i%2B%2B)+
{
++++for+(int+x=0;+x<20;+x%2B%2B)+
++++{
++++++++if+(someBoolValue)
++++++++++++DoThis(x,y);
++++}
}|code-block|syntax|javascript|3139690|当然，另一个例外是使用语句堆叠。|3139691|写作是完全没有意义的|3139692|using+(Stream+x+=+File.Open(...))+
{
++++using+(Stream+y+=+File.Create(...))+
++++{
++++++++...
++++}
}|3139693|当你能写的时候|3139694|using+(Stream+x+=+File.Open(...))
using+(Stream+y+=+File.Create(...))+
{
++++....
}|3139695|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|W|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|Y|8|@]|9|@]|A|$E|F]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I always use curly braces except on the inner most statement, assuming the inner most statement is a single-liner. So my code looks like:

<pre><code>for (int i=0; i&lt;10; i++) 
{
 for (int x=0; x&lt;20; x++) 
 {
 if (someBoolValue)
 DoThis(x,y);
 }
}
</code></pre>

The other exception is of course, stacked using statements.

There's absolutely no sense in writing 

<pre><code>using (Stream x = File.Open(...)) 
{
 using (Stream y = File.Create(...)) 
 {
 ...
 }
}
</code></pre>

when you can write

<pre><code>using (Stream x = File.Open(...))
using (Stream y = File.Create(...)) 
{
 ....
}
</code></pre>

blocks|key|355175|text|保罗说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355176|355177|和缩进与花括号的使用无关。|blockquote|355178|355179|355180|对于某些编码风格，情况并非如此。在我工作的地方，公司的编码标准允许我们在不严格需要的情况下不使用大括号；然而，编码标准让我们缩进大括号以及其中的内容，所以我们最终得到了这样的结果：|355181|if+(something)
++{
++++for+(i+=+0;+i+<+count;+i%2B%2B)
++++++{
++++++++foo();
++++++}
++}|code-block|syntax|javascript|355182|没有大括号，这就变成了：|355183|if+(something
++for+(i+=+0;+i+<+count;+i%2B%2B)
++++foo();|355184|使用这种编码风格，当有很深的嵌套，再加上长的变量和函数名，并且你总是使用大括号，你要么在屏幕的右侧得到大量的代码，要么得到大量的换行，这两者都会使代码阅读或调试变得很麻烦。出于这个原因，只要我能逃脱惩罚，我总是倾向于省略大括号。|355185|至于将单个语句放在与if相同的行上，一些公司的编码标准(包括我们的)禁止这样做，因此它并不总是一个选项。|355186|如果这是我的选择，我会更改公司的编码标准，使大括号的级别与if、for等相同，并将正文中的第一行(或注释)与左大括号放在同一行，如下所示：|355187|if+(something)
{+for+(i+=+0;+i+<+count;+i%2B%2B)
++{+foo();
++}
}|355188|我更愿意(也更有可能)总是使用大括号(甚至支持“总是使用大括号”的规则)，因为每对大括号只会多加一行，没有缩进，这使得它几乎和没有大括号一样紧凑。|355189|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|16|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|19|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1A|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|1C|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|1D|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1E|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|L|7|1G|8|@]|9|@]|A|$M|N]]|$1|10|3|11|5|6|7|1H|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|13|$]]

Paul said:

<blockquote>
 And indentation is independent of brace usage.
</blockquote>

That's not true with some coding styles. Where I work, the company's coding standard allows us to do without braces if they're not strictly necessary; however, the coding standard makes us indent the braces as well as what's in them, so we end up with something like this:

<pre><code>if (something)
 {
 for (i = 0; i &lt; count; i++)
 {
 foo();
 }
 }
</code></pre>

Without the braces, this becomes:

<pre><code>if (something
 for (i = 0; i &lt; count; i++)
 foo();
</code></pre>

With this coding style, when there is deep nesting, together with long variable and function names and you always use braces, you either get lots of code going off the right side of the screen or a lot of line wrapping, both of which, IMO, make the code cumbersome to read or debug. For this reason, I always tend to leave the braces out whenever I can get away with doing so.

As for putting a single statement on the same line as the if, some companies' coding standards (ours included) forbid that, so it's not always an option.

If it were my choice, I would change the company coding standard to have the braces level with the if, for, etc. and have the first line (or comment) in the body on the same line as the opening brace, thus:

<pre><code>if (something)
{ for (i = 0; i &lt; count; i++)
 { foo();
 }
}
</code></pre>

I'd be much more willing (and much more likely) to always use braces then (and would even go so far as to support an 'always use braces' rule), because each pair of braces would add only one extra line and no indentation, making it almost as compact as having no braces at all.

blocks|key|353856|text|在三个约定中：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353857|if(addCurleyBraces())+bugFreeSofware.hooray();|code-block|syntax|javascript|353858|和：|353859|if(addCurleyBraces())
++++bugFreeSofware.hooray();|353860|和(表示使用左和右大括号的任何缩进样式)：|353861|if(addCurleyBraces())+{
++++bugFreeSofware.hooray();
}|353862|我更喜欢最后一个，因为：|353863|353864|我发现如果所有的if语句都写成统一的方式会更容易阅读。|unordered-list-item|353865|这可能会使软件更健壮，没有bug。然而，所有现代的IDE和高级文本编辑器都有很好的自动缩进功能，我认为只要它不会弄乱注释格式或违反团队标准(在许多情况下，可以创建自定义格式方案并与团队共享)，每个人都应该使用它。这里我想说的是，如果缩进做得正确，引入bug的风险就会降低一点。|353866|，|353867|，我更喜欢在不同的行上执行布尔表达式和语句。我喜欢为了调试的目的而标记一行。即使我使用的是集成开发环境，我可以在其中标记一条语句并单步执行它，但这是一个交互式操作，我可能会忘记从哪里开始调试，或者至少需要多花一点时间来单步执行代码几次(因为每次调试期间我都必须手动标记该位置)。|353868|353869|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|14|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|15|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|16|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|17|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|18|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|1B|8|@]|9|@]|A|$]]|$1|U|3|V|5|T|7|1C|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|T|7|1E|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|12|$]]

Out of the three conventions:

<pre><code>if(addCurleyBraces()) bugFreeSofware.hooray();
</code></pre>

and:

<pre><code>if(addCurleyBraces())
 bugFreeSofware.hooray();
</code></pre>

and (which represent any indentation style using an opening and a closing brace):

<pre><code>if(addCurleyBraces()) {
 bugFreeSofware.hooray();
}
</code></pre>

I prefer the last one as:

<ul>
<li>I find it easier to read if all the if-statements are written in a uniform way.</li>
<li>It may make the software a tiny bit more robust and bug free. However all modern IDE's and advanced text editors have nice auto-indenting features which I think everyone should use as long as it doesn't mess up comment formatting or go against team standards (in a lot of cases it's possible to create a custom formatting scheme and share it with the team). My point here is that if indentation is done correctly risk of bug introduction is reduced a bit.</li>
<li>I prefer the boolean expression and statement(s) to execute to be on different lines. I like to be able to mark a row for debugging purposes. Even if I'm using an IDE where I may mark a statement and step to it, it's an interactive operation and I might forget where I started to debug or at least it will take me a little bit more time to step through the code several times (as I have to mark the position manually each time during debugging).</li>
</ul>

blocks|key|356027|text|阅读速度...|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|356028|除了已经提到的内容之外。此时，我已经习惯于解析带大括号和空格的if语句。所以我读到：|356029|if+(condition)
{
++++DoSomething();
}

DoSomethingElse();|code-block|syntax|javascript|356030|比我读得快一点：|356031|if+(condition)+DoSomething();

DoSomethingElse();|356032|如果它看起来像这样，我会读得慢一点：|356033|if+(condition)+DoSomething();
DoSomethingElse();|356034|我读这篇文章的速度比上一篇慢得多：|356035|if+(condition)+
++++DoSomething();
DoSomethingElse();|356036|因为我忍不住又读了一遍，以防万一，不知道作者是不是故意的：|356037|if+(condition)
{
++++DoSomething();
++++DoSomethingElse();
}|356038|已经在一般情况下讨论过了，但是当涉及到下面的阅读时，我将研究很长一段时间以确定作者的意图。我甚至可能会找到原作者来确认。|356039|if+(condition)+
++++DoSomething();
++++DoSomethingElse();|356040|entityMap^0|0|7|0|0|0|0|0|0|0|0|0|0|0|M|2|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1B|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|1C|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1D|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|1E|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1F|8|@]|D|@]|E|$]]|$1|S|3|T|5|J|7|1G|8|@]|D|@]|E|$K|L]]|$1|U|3|V|5|6|7|1H|8|@]|D|@]|E|$]]|$1|W|3|X|5|J|7|1I|8|@]|D|@]|E|$K|L]]|$1|Y|3|Z|5|6|7|1J|8|@]|D|@]|E|$]]|$1|10|3|11|5|J|7|1K|8|@]|D|@]|E|$K|L]]|$1|12|3|13|5|6|7|1L|8|@$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|14|3|15|5|J|7|1O|8|@]|D|@]|E|$K|L]]|$1|16|3|-4|5|6|7|1P|8|@]|D|@]|E|$]]]|17|$]]

Speed of reading...

Aside from what has already been mentioned. At this point, I've already been conditioned to parse if statements with braces and white space. So I read:

<pre><code>if (condition)
{
 DoSomething();
}

DoSomethingElse();
</code></pre>

Slightly faster than I read:

<pre><code>if (condition) DoSomething();

DoSomethingElse();
</code></pre>

I read it a little slower if it looks like this:

<pre><code>if (condition) DoSomething();
DoSomethingElse();
</code></pre>

I read this significantly slower than the prior:

<pre><code>if (condition) 
 DoSomething();
DoSomethingElse();
</code></pre>

beause I can't help but read it again just in-case and wonder if the author intended:

<pre><code>if (condition)
{
 DoSomething();
 DoSomethingElse();
}
</code></pre>

Already covered in general, but when it comes to reading the below, I'll be looking into this for quite a while to make sure what the author intended. I may even hunt down the original author to confirm.

<pre><code>if (condition) 
 DoSomething();
 DoSomethingElse();
</code></pre>

blocks|key|3139772|text|我认为这一切都归结为偏好和可读性。通常，添加大括号将使您的代码更具可读性，因为实际的代码行之间有额外的空格。另外，考虑这个例子(不是故意缩进的)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139773|if+(condition1)
if+(condition2)
doSomething();
else
doSomethingElse();|code-block|syntax|javascript|3139774|什么时候调用doSomethingElse？当condition1为true但condition2为false时，或者当condition1为false时？添加大括号可以快速解决这个可读性问题，并避免混淆。|3139775|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I think it all boils down to preference and readability. Generally adding curly braces will make your code a lot more readable because of the extra space between the actual lines with code. Also, consider this example (not indented on purpose):

<pre><code>if (condition1)
if (condition2)
doSomething();
else
doSomethingElse();
</code></pre>

When does doSomethingElse get called? When condition1 is true but condition2 is false, or when condition1 is false? Adding curly braces quickly solves this readability problem and avoids confusion.

blocks|key|358583|text|另一种结合了两者优点的方法是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358584|if(foo)
+++{DoSomething();}|code-block|syntax|javascript|358585|如果该行被注释掉，或者在该行下面添加了另一行，这样就避免了任何混淆。|358586|此外，我们使用MISRA-C作为编码标准，它要求所有像这样的构造在所有情况下都要使用大括号。|offset|length|358587|entityMap|0|LINK|mutability|MUTABLE|url|http://www.misra.org.uk/^0|0|0|0|7|7|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|X|8|@]|9|@$K|Y|L|Z|1|10]]|A|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

An alternative method which combines the best of both worlds is this:

<pre><code>if(foo)
 {DoSomething();}
</code></pre>

This avoids any confusion if the line is commented out, or another line is added below it.

Also, we use <a href="http://www.misra.org.uk/" rel="nofollow noreferrer">MISRA-C</a> as a coding standard, which requires all constructs like this to use braces under all circumstances.

blocks|key|3139780|text|在大多数情况下，我更喜欢大括号。通常，您会返回到代码来添加更多的代码行，而且无论如何都必须添加它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139781|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I prefer braces in most situations. Often you'll come back to the code to add more lines of code and you'll have to add them anyway.

blocks|key|355217|text|关于为什么不应该这样做，这里有很多很好的答案--我也同意不应该省略大括号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355218|如果您正在寻找更简洁的代码，我实际上可以使用三元语句。它们提供了紧凑性和一定的清晰度，并且更能抵抗意外。|355219|正如前面提到的，省略大括号的问题是事后出错的可能性。大多数程序员都会同意，他们可以阅读：|355220|if(+foo+)
++++bar();|code-block|syntax|javascript|355221|当人们来修改声明而不注意时，问题就来了。在我工作的最后一个地方，有人修改语句或注释掉了一行，实际上出现了一个问题。一个编码标准已经到位，以确保类似的bug永远不会再次发生。|355222|正如其他人所说，程序员的时间是昂贵的。就像注释你的代码一样，省略它们通常会更快，因为它们是可选的，但易于维护的代码通常依赖于那些“可选”的东西。|355223|最后，有人提到现代编辑器和IDE应该自动缩进，并自动显示作用域。我的答案是不要像拐杖一样使用这些东西。有时，当您查看源代码库之外的代码时，或者通过远程连接，甚至是在电子邮件中--这些都是开发的现实。您可能没有IDE或高级编辑器来显示您做错了什么。总是写你的代码，让它是可理解的，无论你把它加载到什么地方。|355224|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

There's a lot of good answers here about why you shouldn't -- and I'm on the side that agrees that you shouldn't omit braces.

If you're looking for more terse code, I'd actually work with a ternary statement. They provide compactness with a certain amount of unambiguity and are more resistant to accidents.

The problem with omitting braces, as mentioned, is the likelihood of mistakes after the fact. Most programmers will agree that they can read:

<pre><code>if( foo )
 bar();
</code></pre>

The problem comes when people come and change the statement and don't pay attention. At the last place I worked, there was actually a problem that arose from someone modifying the statement or commenting out a line. A coding standard was put in place to make sure bugs like that never happened again.

As someone else said, programmer time is the expensive bit. Like commenting your code, it's often faster to just leave out bits because they're optional, but easily maintainable code often relies on those 'optional' things.

Lastly, some people have mentioned that modern editors and IDEs should auto-indent and show you scope automatically. My answer is to not use such things as a crutch. There are times when you're looking at code out of a source repository or over a remote connection or even in an email -- these are the realities of development. You may not have an IDE or advanced editor to show you what you're doing wrong. Always write your code so that it's understandable no matter what you load it in.

blocks|key|3352625|text|我以前也很讨厌牙套。直到有一天我发现了它们的用处。我在不同的平台上工作，将应用程序从一个平台移植到另一个平台(总共工作了6个)。在UNIX上，如果您安装了vim，那么您可以通过按下'Shift+%2B+5‘轻松地跳到代码块的结尾或开头。这些主要是if/else块或循环。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352626|因此，如果我在vim上查看Rampion的问题，我会完全迷失方向，并且需要一段时间才能完全理解代码。|3352627|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I used to hate the braces myself. Until one day I found a use for them. I work on different platforms porting the application from platform to platform (work on 6 in total). On UNIX if you have vim installed, then you can easily jump to the ending or beginning of a code block by pressing 'Shift + 5'. These mostly are if/else blocks or loops.

So if i were looking at Rampion's problem on vim, I'd be totally lost and would take me a while to fully understand the code.

blocks|key|353897|text|使用一些个人判断。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353898|if+(foo)
++bar();|code-block|syntax|javascript|353899|本身就很好。除非你真的担心笨蛋以后会放进这样的东西：|353900|if+(foo)
++bar();
++baz();|353901|如果你不担心笨蛋，你就很好(我不担心--如果他们不能正确地掌握基本的代码语法，这是他们最小的问题)>|353902|作为交换，它的可读性要好得多。|353903|剩下的时间：|353904|if+(foo)+{
++bar();
++baz();
}|353905|从我记事起就一直是我的最爱。此外：|353906|if+(foo)+{
++bar();
++baz();
}+else+{
++qux();
}|353907|这对我很有效。|353908|垂直空间本身并不是很重要，但可读性却很重要。一行上的左大括号本身只是停止了语法元素的对话，直到你的视线移到下一行。不是我喜欢的。|353909|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1D|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|11|$]]

Use some personal judgement.

<pre><code>if (foo)
 bar();
</code></pre>

is fine by itself. Unless you're really worried about morons putting in something like this later:

<pre><code>if (foo)
 bar();
 baz();
</code></pre>

If you're not worried about morons, you're fine (I'm not -- if they can't get basic code syntax right, this is the least of their problems)>

In exchange, it's a lot more readable.

The rest of the time:

<pre><code>if (foo) {
 bar();
 baz();
}
</code></pre>

Which has been my favorite as long as I can remember. Additionally:

<pre><code>if (foo) {
 bar();
 baz();
} else {
 qux();
}
</code></pre>

Works for me. 

Vertical space by itself isn't terribly relevant, readability is. The opening brace on a line by itself just stops the conversation for a syntactic element, until your eye moves down to the next line. Not what I like.

blocks|key|358595|text|为了将来的可读性，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358596|空格是缩进的，这意味着取决于制表符的设置，这不是一个好主意。有没有在十年前的代码上工作过，但这些代码不在修订控制之下？|ordered-list-item|358597|我的经验是，你不输入大括号节省的任何时间，都会因为我花了额外的时间来理解你的意思而失去更多。|358598|358599|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|K|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|L|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

<ol>
<li>Whitespace is free.</li>
<li>Depending on indentation for future readability means depending on tab settings, which is not a good idea. Ever worked on ten-year-old code that wasn't under revision control?</li>
<li>My experience is that any time you saved by not typing curly braces is more than lost by the extra time it takes me to figure out what you meant.</li>
</ol>

blocks|key|3139808|text|我也喜欢更紧凑的格式。这就是为什么我经常在Visual+Studio中点击Ctrl%2BK，Ctrl%2BD来重新格式化。我只希望每次按键后都能让它为我做这件事。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139809|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I like the more compact formatting too. This is why I'm constantly hitting Ctrl+K, Ctrl+D to reformat in Visual Studio. I just wish I could make it do this for me after every keypress.

blocks|key|358601|text|我过去也是这样想的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358602|直到有一天(为什么总有“一天”永远改变你的生活？)我们花了24+-+36个小时不睡觉调试生产代码，结果发现有人没有把大括号和搜索/替换更改结合在一起。|358603|大概是这样的。|358604|+if(+debugEnabled+)+
++++++println(+"About+to+save+1+day+of+work+to+some+very+important+place.");
+saveDayData();|code-block|syntax|javascript|358605|接下来的是|358606|+if(+debugEnabled+)+
+//+++++println(+"About+to+save+1+day+of+work+to+some+very+important+place.");
+saveDayData();|358607|原来系统每天产生500mb的日志，我们被要求停止它。调试标志不够，因此需要搜索并替换println。|358608|尽管如此，当应用程序投入生产时，调试标志是关闭的，并且从未调用过重要的"saveDayData“。|358609|编辑|offset|length|style|BOLD|358610|现在，我唯一不使用大括号的地方是if/try构造。|358611|if(+object+!=+null+)+try+{+
+++++object.close();
}+catch(+.....|358612|在看到一位超级巨星开发者这么做之后。|358613|entityMap^0|0|0|0|0|0|0|0|0|0|2|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1A|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|1B|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@$U|1F|V|1G|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|11|5|H|7|1I|8|@]|9|@]|A|$I|J]]|$1|12|3|13|5|6|7|1J|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|15|$]]

I use to think the same way.

Until one day ( why is there always that "one day" that changes your life forever? ) we spend from 24 - 36 hours straight without sleep debugging production code only to find out someone didn't put braces combined with a search/replace change. 

It was something like this.

<pre><code> if( debugEnabled ) 
 println( "About to save 1 day of work to some very important place.");
 saveDayData();
</code></pre>

What came after was 

<pre><code> if( debugEnabled ) 
 // println( "About to save 1 day of work to some very important place.");
 saveDayData();
</code></pre>

It turns out that the system was generating 500 mb of logs daily and we were asked to stop it. The debug flag was not enough so a search and replace println was in order.

Still when the app went to production the debug flag was off and the important "saveDayData" was never called. 

EDIT 

Now the only place where I don't use the braces is in if/try construct.

<pre><code>if( object != null ) try { 
 object.close();
} catch( .....
</code></pre>

After watching a superstar developer doing that.

blocks|key|355252|text|好了，这是一个古老的问题，答案已经到了死亡。我有话要补充。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355253|首先，我只需要说使用大括号。它们只会提高可读性和可读性(对您自己和其他人都是如此！)在你的优先级列表中应该是非常高的，除非你正在编写程序集。不可读的代码总是会导致错误。如果您发现大括号使您的代码占用太多空间，那么您的方法可能太长了。任何方法的大部分或全部都应该适合一个屏幕高度，如果你做得正确的话，而Find+(F3)是你的朋友。|355254|现在是我的补充:这有一个问题：|355255|if+(foo)+bar();|code-block|syntax|javascript|355256|尝试设置一个断点，该断点仅在bar()将要运行时才会命中。在C#中，可以通过将光标放在代码的后半部分来实现这一点，但这并不明显，而且有点麻烦。在C%2B%2B中，你根本无法做到这一点。由于这个原因，我们在C%2B%2B代码上工作的一位最资深的开发人员坚持将'if‘语句分成两行。我同意他的观点。|355257|所以要这样做：|355258|if+(foo)
{
++++bar();+//It+is+easy+to+put+a+breakpoint+here,+and+that+is+useful.
}|355259|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|Y|8|@]|9|@]|A|$I|J]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Okay, this is an old question that has been answered to death. I have something to add. 

First I just have to say USE THE BRACES. They can only help readability, and readability (for yourself and others!) should be very high on your priority list unless you're writing assembly. Unreadable code always, always leads to bugs. If you find that braces make your code take up too much space, your methods are probably too long. Most or all of any method should fit within one screen height if you're doing it right, and Find (F3) is your friend.

Now for my addition: There is a problem with this:

<pre><code>if (foo) bar();
</code></pre>

Try setting a breakpoint that will only be hit if bar() is going to run. You can do this in C# by putting the cursor on the second half of the code, but that is not obvious and is a bit of a pain. In C++ you couldn't do it at all. One of our most senior developers working on C++ code insists on breaking 'if' statements into two lines for this reason. And I agree with him.

So do this:

<pre><code>if (foo)
{
 bar(); //It is easy to put a breakpoint here, and that is useful.
}
</code></pre>

blocks|key|3352662|text|因为StyleCop这么说。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352663|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|3352669|text|如果你觉得“有时”有大括号是有用的，你应该总是添加大括号以保持一致。程序应该写成供人阅读，而不是计算机。我更喜欢像这样的花括号：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352670|if+(mybool)
{
++doMyStuff();
}
else
{
++doMyOtherStuff();
++checkStuff();
}|code-block|syntax|javascript|3352671|也不喜欢|3352672|if+(mybool)+{
++doMyStuff();
}
else+{
++doMyOtherStuff();
++checkStuff();
}|3352673|3352674|+++if+(mybool)
+++++doMyStuff();+
+++else+
+++{++
+++++doMyOtherStuff();
+++++checkStuff();+
+++}|3352675|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Q|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|R|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|S|8|@]|9|@]|A|$E|F]]|$1|K|3|H|5|6|7|T|8|@]|9|@]|A|$]]|$1|L|3|M|5|D|7|U|8|@]|9|@]|A|$E|F]]|$1|N|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|O|$]]

If you feel "sometimes" it is useful to have braces, you should aways add braces to be consistant.
Programs should be written to be read by people not computers.
I prefer braces like:

<pre><code>if (mybool)
{
 doMyStuff();
}
else
{
 doMyOtherStuff();
 checkStuff();
}
</code></pre>

and NOT like

<pre><code>if (mybool) {
 doMyStuff();
}
else {
 doMyOtherStuff();
 checkStuff();
}
</code></pre>

and not like

<pre><code> if (mybool)
 doMyStuff(); 
 else 
 { 
 doMyOtherStuff();
 checkStuff(); 
 }
</code></pre>

blocks|key|3352677|text|另一方面，如果您删除/不使用大括号来保存行，则需要重构代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3352678|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

On other thought, if you are removing/not using braces to save lines, you need to refactor the code.

blocks|key|355270|text|它们告诉您是因为它们仍然使用古老的或通用的(不支持语言的)源代码编辑器。如果你使用一个带有自动缩进的编辑器，你永远不会犯一个错误，而这个错误本可以通过一直使用花括号来避免。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355271|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

They tell you because they still use ancient or generic (not language-aware) source code editors.
If you use an editor with auto-indent, you will never make a mistake that could have been avoided by using curly brackets all the time.

blocks|key|356081|text|坦率地说，我是这样看的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356082|优秀的程序员会防御性编程，而糟糕的程序员则不会。|356083|由于上面有几个例子，而且我自己也有类似的关于忘记大括号的bug的经验，所以我学会了总是放大括号的艰难之路。|356084|其他的都是选择个人风格而不是安全，这显然是糟糕的编程。|356085|乔尔甚至在Making+Wrong+Code+Look+Wrong中提到了这一点|offset|length|356086|一旦您因为缺少大括号而被bug咬到，您就会发现缺少大括号看起来是错误的，因为您知道这是另一个bug可能发生的地方。|356087|entityMap|0|LINK|mutability|MUTABLE|url|http://www.joelonsoftware.com/articles/Wrong.html^0|0|0|0|0|5|S|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$J|10|K|11|1|12]]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

To be blunt I see it as:

Good programmers program defensively, Bad programmers don't.

Since there are several examples above and my own similar experiences with bugs related to forgetting braces then I learned the hard way to ALWAYS PUT BRACES.

Anything else is choosing personal style over safety and that's clearly bad programming.

Joel even mentions this in <a href="http://www.joelonsoftware.com/articles/Wrong.html" rel="noreferrer">Making Wrong Code Look Wrong</a>

Once you get bit by a bug because of missing braces you learn that missing braces look wrong because you know it's a potential place for another bug to occur.

blocks|key|3139873|text|我很乐意：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139874|foreach+(Foo+f+in+foos)
++foreach+(Bar+b+in+bars)
++++if+(f.Equals(b))
++++++return+true;

return+false;|code-block|syntax|javascript|3139875|就我个人而言，我不明白为什么|3139876|foreach+(Foo+f+in+foos)
{
++foreach+(Bar+b+in+bars)
++{
++++if+(f.Equals(b))
++++{
++++++return+true;
++++}
++}
}

return+false;|3139877|更具可读性。|3139878|是的，行是免费的，但是为什么我必须滚动浏览页面和页面的代码，而它可能是一半的大小？|3139879|如果在可读性或可维护性方面存在差异，那么，当然，在...但在这种情况下，我看不到任何理由。|3139880|此外，我将始终在嵌套的if的位置放置大括号|3139881|if+(condition1)
++if+(condition2)
++++doSomething();
++else+(condition2)
++++doSomethingElse();|3139882|vs|3139883|if+(condition1)
++if+(condition2)
++++doSomething();
else+(condition2)
++doSomethingElse();|3139884|非常令人困惑，所以我总是这样写：|3139885|if+(condition1)
{
++if+(condition2)
++++doSomething();
++else+(condition2)
++++doSomethingElse();
}|3139886|只要有可能，我就会使用三元运算符，但我从不使用nest+them。|offset|length|3139887|entityMap|0|LINK|mutability|MUTABLE|url|http://thedailywtf.com/Articles/Turn_it_up_to_Eleven.aspx^0|0|0|0|0|0|0|0|0|0|0|0|0|0|N|9|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1F|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1G|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1H|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1I|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1J|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1L|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|1M|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|1N|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|1O|8|@]|9|@]|A|$E|F]]|$1|Y|3|Z|5|6|7|1P|8|@]|9|@]|A|$]]|$1|10|3|11|5|D|7|1Q|8|@]|9|@]|A|$E|F]]|$1|12|3|13|5|6|7|1R|8|@]|9|@$14|1S|15|1T|1|1U]]|A|$]]|$1|16|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]]]

I'm quite happy to:

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

return false;
</code></pre>

Personally, I don't see why

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

return false;
</code></pre>

is any more readable.

Yes, lines are free, but why should I have to scroll through pages and pages of code when it could be half the size?

If there is a difference in readability or maintainability then, sure, put braces in... but in this case I don't see any reason to.

Also, I will always put braces for nested if's where I have nested else's

<pre><code>if (condition1)
 if (condition2)
 doSomething();
 else (condition2)
 doSomethingElse();
</code></pre>

vs

<pre><code>if (condition1)
 if (condition2)
 doSomething();
else (condition2)
 doSomethingElse();
</code></pre>

is terribly confusing, so I always write it as:

<pre><code>if (condition1)
{
 if (condition2)
 doSomething();
 else (condition2)
 doSomethingElse();
}
</code></pre>

Whenever possible, I use ternary operators, but I never <a href="http://thedailywtf.com/Articles/Turn_it_up_to_Eleven.aspx" rel="noreferrer">nest them</a>.

Why does everyone tell me writing code like this is a bad practice?

<pre><code>if (foo)
 Bar();

//or

for(int i = 0 i &lt; count; i++)
 Bar(i);
</code></pre>

My biggest argument for omitting the curly braces is that it can sometimes be twice as many lines with them. For example, here is some code to paint a glow effect for a label in C#.

<pre><code>using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
 for (int x = 0; x &lt;= GlowAmount; x++)
 {
 for (int y = 0; y &lt;= 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 &lt;= GlowAmount; x++)
 for (int y = 0; y &lt;= GlowAmount; y++)
 g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
</code></pre>

You can also get the added benefit of chaining <code>usings</code> together without having to indent a million times.

<pre><code>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
}
</code></pre>

<hr>

The most common argument for curly braces revolves around maintance programming, and the problems that would ensue by inserting code between the original if statement and its intended result:

<pre><code>if (foo)
 Bar();
 Biz();
</code></pre>

<hr>

<h3>Questions:</h3>

<ol>
<li>Is it wrong to want to use the more compact syntax which the language offers? The people that design these languages are smart, I can't imagine they would put a feature which is always bad to use.</li>
<li>Should we or Shouldn't we write code so the lowest common denominator can understand and have no problems working with it? </li>
<li>Is there another argument that I'm missing?</li>
</ol>

Why is it considered a bad practice to omit curly braces?

集成开发环境

Visual Studio

单元测试

编译器

Python

为什么每个人都告诉我像这样写代码是一种糟糕的做法？if (foo) Bar();//orfor(int i = 0 i < count; i++) Bar(i);我对省略大括号的最大理由是，有时花括号的行数可能是花括号的两倍。例如，下面是在C#中为标签绘制发光效果的一些代码。using (Brush br ...

问为什么省略大括号被认为是一种糟糕的做法？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么省略大括号被认为是一种糟糕的做法？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么省略大括号被认为是一种糟糕的做法？
EN