为什么每个人都告诉我编写这样的代码是一种不好的做法？
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();
答案 0 :(得分：179)
实际上，唯一真正让我感到困惑的是我在调试时，并注释掉了bar（）：
if(foo)
// bar();
doSomethingElse();
除此之外，我倾向于使用：
if(foo) bar();
负责上述案件。
编辑感谢您澄清问题，我同意，我们不应该将代码写入最低标准。
答案 1 :(得分：153)
阅读速度......
除了已经提到的内容之外。在这一点上，我已经习惯于使用大括号和空格来解析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();
答案 2 :(得分：54)
如果它很小，请按以下方式编写：
if(foo()) bar();如果它足够长，可以分成两行，请使用大括号。
答案 3 :(得分：45)
我也常常认为最好只在真正需要时使用牙箍。但不再是，主要原因是，当你有很多代码时，它确实使它更具可读性，你可以在拥有一致的支撑风格时更快地解析代码。
除了有人在if上添加第二个语句之外，总是使用大括号的另一个好理由是这样的事情会发生：
if(a)
if(b)
c();
else
d();
您是否注意到else子句实际上是“if（b）”的子句？你可能做过，但是你会相信任何人都熟悉这个问题吗？
所以，如果只是为了保持一致性，并且因为你永远不知道别人会发生什么意外事情（它总是其他人都是愚蠢的）改变代码，我总是把括号，因为它使源代码更易读，更容易被大脑解析。仅对于最简单的if语句，例如在制作委托或类似开关的情况下，如果您知道该子句永远不会被扩展，我会省略括号。
答案 4 :(得分：35)
这并不总是被认为是一种不好的做法。如果没有必要，Mono Project Coding Guidelines建议不要使用花括号。 GNU Coding Standards也是如此。我认为这与个人品味一样，与编码标准一样。
答案 5 :(得分：35)
我更喜欢大括号提供的清晰度。你确切地知道是什么意思，不必猜测是否有人只是愚蠢而把它们关掉（并引入了一个bug）。我省略它们的唯一一次是将if和action放在同一行上。我也不经常这样做。我实际上更喜欢通过将花括号放在自己的行上而引入的空白，尽管从多年的K＆amp; R C类编程开始，用支撑结束这一行是我必须努力克服的一个实践，如果IDE不强制执行它适合我。
if (condition) action(); // ok by me
if (condition) // normal/standard for me
{
action();
}
答案 6 :(得分：34)
线很便宜。处理器功率很便宜。开发人员的时间非常昂贵。
作为一般规则，除非我正在开发一些绝对资源/速度关键的应用程序，否则我总是会错误地编写代码
（a）任何其他开发人员都可以轻松地遵循我正在做的事情
（b）评论可能需要它的代码的特定部分
（c）如果出现问题，可以轻松调试
（d）如果将来需要（即添加/删除代码），则易于修改
从业务角度来看，代码的速度或学术优雅是次要的。这并不是说我打算编写笨重或丑陋的代码，但这是我的优先顺序。
在大多数情况下省略花括号，对我来说，（b），（c）和（d）更难（注意不是不可能）。我会说使用花括号或不使用花括号对（a）没有影响。
答案 7 :(得分：23)
我认为这是您正在进行的项目和个人品味的准则问题。
我通常在不需要它们时省略它们，除了以下一些情况：
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
}
答案 8 :(得分：15)
在C / C ++宏的旧时代，这可能会让你感到困惑的一个例子。我知道这是一个C＃问题，但是编码标准通常会在没有创建标准的原因的情况下继续存在。
如果在创建宏时不是很小心，最终可能会导致if语句出现问题而不会使用{}。
#define BADLY_MADE_MACRO(x) function1(x); function2(x);
if (myCondition) BADLY_MADE_MACRO(myValue)
现在，不要误解我的意思，我不是说你应该总是这样做以避免在C / C ++中出现这个问题，但是由于这个原因，我不得不处理一些非常奇怪的错误。 / p>
答案 9 :(得分：15)
我用同样的方式思考。
直到有一天（为什么总会有“一天”永远改变你的生活？）我们花了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( .....
在观看了一位超级明星开发者之后。
答案 10 :(得分：14)
我很高兴：
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 if我嵌套其他的
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
VS
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
非常令人困惑，因此我总是把它写成：
if (condition1)
{
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
}
尽可能使用三元运算符，但我从不 nest them。
答案 11 :(得分：12)
坦率地说，我认为：
优秀的程序员在防御程序上编程，坏程序员不会。
由于上面有几个例子和我自己类似的与忘记括号有关的错误的经历，所以我学会了总是坚持不懈的方法。
其他任何事情都是选择个人风格而不是安全，这显然是错误的编程。
乔尔甚至在Making Wrong Code Look Wrong
中提到了这一点一旦你因为缺少大括号而得到一个bug，你会发现丢失的大括号看起来是错误的，因为你知道它可能会发生另一个bug。
答案 12 :(得分：10)
令我印象深刻的是，我在计算机编程领域的同行（你很多）并没有因为你在单行块上跳过大括号时潜在的错误而感到沮丧。
我想这意味着我不聪明。我多次犯了这个错误。我调试了其他人的错误。我已经看过因为这个问题导致软件出现错误（运行VS2002的机器的RDP以及你的手表窗口字体会变得不稳定）。
如果我看看我所做的所有错误，可以通过改变编码风格来避免，列表很长。如果我在每种情况下都没有改变我的方法，我可能永远不会成为程序员。再说一遍，我想我不聪明。为了弥补这一点，我长期以来一直是单线模块上大括号的坚定用户。
那就是说，世界上有些事情发生了变化，使得“你在单行街区上使用大括号”的规则与摩西把它带到我们身上相比不那么重要了：
一些流行的语言通过让计算机读取缩进来解决问题，就像程序员那样（例如Python）。
我的编辑器为我自动格式化，因此我因缩进误导的可能性大大降低。
TDD 意味着如果我引入了一个错误，因为我对单行块感到困惑，我更有可能快速发现错误。
重构和语言表达意味着我的块更短，并且单行块的发生频率比使用时更频繁。假设有一个无情的ExtractMethod应用程序，我可能在整个程序中只有 单行块。 （我想知道那会是什么样的？）
事实上，无情地重构可以带来明显的好处。省略单行块上的大括号：当你看到大括号时，头上会发出一个小小的警报，说“这里有复杂性！小心！”。想象一下，如果这是常态：
if (condition) Foo(); // normal, everyday code
if (condition)
{
// something non-trivial hapening; pay attention!
Foo();
Bar();
}
我打开自己的想法，将我的编码约定更改为“单行块可能永远不会有大括号”或“如果你可以将块放在与条件相同的行上，这一切都适合于80个字符，省略大括号“。我们会看到。
答案 13 :(得分：10)
我同意“如果你足够聪明，可以让某人付钱给你编写代码，那么你应该足够聪明，不要仅仅依靠缩进来查看代码的流程。”
然而......可能会犯错误，而这个错误很难调试......特别是如果你正在查看其他人的代码。
答案 14 :(得分：10)
我的理念是，如果它使代码更具可读性，为什么不这样做呢？
显然你必须在某处绘制线条，比如在简洁和过于描述的变量名称之间找到快乐的媒介。但括号确实可以避免错误并提高代码的可读性。
你可以说，聪明到足以成为程序员的人会变得足够聪明，以避免引发无括号语句的错误。但你真的可以说你从来没有像拼写错误这样简单的东西被绊倒吗？在看大型项目时，这样的细节可能会让人不知所措。
答案 15 :(得分：10)
我偶尔使用最底层的代码（多个使用语句），但除此之外我总是把括号放进去。我发现它使代码更清晰。显而易见的是，除了缩进之外，语句是块的一部分（因此可能是if等的一部分）。
我见过
if (...)
foo();
bar();
bug咬我（或者更确切地说是“我和同事” - 我实际上没有介绍这个错误）一次。尽管我们当时的编码标准建议在任何地方使用括号。我花了很长时间才发现 - 因为你看到了你想要看到的东西。 （这是大约10年前的事。也许我现在发现它更快。）
当然如果你使用“支撑在行尾”它会减少额外的线路，但我个人不喜欢这种风格。 （我在工作中使用它，发现它不如我预期的那么令人不愉快，但它仍然有点不愉快。）
答案 16 :(得分：10)
总会有例外情况，但我认为只有当它采用其中一种形式时才会忽略大括号：
if(x == y) for(/* loop */) { //200 lines } //rampion's example: for(/* loop */) { for(/* loop */) for(/* loop */) { //several lines } }
否则，我没有问题。
答案 17 :(得分：9)
三项公约中的一项：
if(addCurleyBraces()) bugFreeSofware.hooray();
和
if(addCurleyBraces())
bugFreeSofware.hooray();
和（表示使用开口和右括号的任何缩进样式）：
if(addCurleyBraces()) {
bugFreeSofware.hooray();
}
我更喜欢最后一个：
答案 18 :(得分：8)
我非常相信编写简洁明了的代码，但我总是会使用花括号。我发现它们是一种快速查看特定代码行存在范围的便捷方式。没有歧义，它只是在你面前明确提出。
有些人可能会说这是一个偏好的情况，但我发现程序的逻辑流程如果内部一致则更容易遵循，我不相信写一个这样的IF语句是一致的;
if(x < y)
x = y;
else
y = x;
另一个像这样;
if(x < y)
{
x = y;
x++;
}
else
{
y = x;
y++;
}
我更喜欢选择一种一般风格并坚持下去：）
答案 19 :(得分：8)
反对使用大括号的主要论点是他们使用额外的行并且需要额外的缩进。
行（几乎）是免费的，最小化代码中的行数不应该是一个目标。
缩进与大括号的使用无关。在你的级联'使用'示例中，我仍然认为即使你省略大括号也应该缩进它们。
答案 20 :(得分：7)
使用一些个人判断。
if (foo)
bar();
本身很好。除非你真的担心傻瓜后来会这样做：
if (foo)
bar();
baz();
如果你不担心蠢货，你很好（我不是 - 如果他们不能正确地获得基本的代码语法，这是他们最少的问题）＆gt;
作为交换，它更具可读性。
剩下的时间：
if (foo) {
bar();
baz();
}
只要我记得，这就是我的最爱。此外：
if (foo) {
bar();
baz();
} else {
qux();
}
适合我。
垂直空间本身并不十分相关，可读性也是如此。一条直线上的左括号只会停止语法元素的对话，直到你的眼睛向下移动到下一行。不是我喜欢的。
答案 21 :(得分：7)
我曾经是“花括号必须！”的巨大支持者，但自从采用单元测试后，我发现我的单元测试可以保护无括号语句，例如：
if (foo)
snafu();
bar();
通过良好的单元测试，我可以放心地省略大括号的简单语句以提高可读性（是的，这可能是主观的）。
或者，对于类似上述的内容，我可能会将其描述为：
if (foo) snafu();
这样，需要在条件中添加bar（）的开发人员更容易识别缺少花括号，并添加它们。
答案 22 :(得分：7)
好的，这是一个已经回答死亡的老问题。我有一些要补充的东西。
首先，我必须说使用支架。它们只能帮助提高可读性，并且可读性（对于您自己和他人！）应该在您的优先级列表中非常高，除非您正在编写程序集。总是无法读取的代码，总是会导致错误。如果你发现大括号会让你的代码占用太多空间，那么你的方法可能太长了。如果你做得对，大多数或所有方法都应该适合一个屏幕高度，而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.
}
答案 23 :(得分：7)
主要问题之一是当你有单行和非单行的区域时，
以及与控制语句的分离（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
}
答案 24 :(得分：6)
为了防止代码占用大量空间，我使用了书中Code Complete推荐的技术：
if (...) {
foo();
bar();
}
else {
...
}
答案 25 :(得分：6)
假设你有一些代码：
if (foo)
bar();
然后其他人出现并添加：
if (foo)
snafu();
bar();
根据它的写法，bar（）;现在无条件执行。通过包含花括号，可以防止出现这种意外错误。编写代码的方式应该是难以或不可能犯这样的错误。如果我正在进行代码审查并看到缺少的大括号，特别是分布在多行中，我会创建一个缺陷。在合理的情况下，将其保持在一行，以便将出现这种错误的可能性再次保持在最低限度。
答案 26 :(得分：6)
减少行数并不是删除大括号的好理由。如果您的方法太大，它可能应该重构为较小的部分或重组。这样做无疑会提高可读性，而不仅仅是取出括号。
答案 27 :(得分：5)
我总是在适当的时候省略它们，例如在你的第一个例子中。清晰，简洁的代码我可以通过浏览来查看和理解，比我必须逐行滚动和逐行读取的代码更容易维护，调试和理解。我想大多数程序员都同意这一点。
如果你开始做多个嵌套，if / else子句等等，它很容易失控，但我认为大多数程序员应该能够知道在哪里画线。
我认为它有点像if ( foo == 0 ) vs if ( 0 == foo )的论点。后者可以防止新程序员的错误（甚至可能偶尔为退伍军人），而前者在维护代码时更容易快速阅读和理解。
答案 28 :(得分：4)
大多数情况下，无论是公司还是自由和开放源码软件项目，它都是一种编码标准。
最终，其他人需要了解您的代码，每个开发人员必须弄清楚他们正在处理的代码部分的具体样式，这是一个主要的时间流失。
另外，想象一下有人每天不止一次地在Python和Cish语言之间进行...在Python中，缩进是语言的块语义的一部分，并且很容易犯一个像你这样的错误报价。
答案 29 :(得分：3)
Err更安全 - 只有一个你可能无需修复的bug。
如果我的所有积木被包裹在卷曲中，我个人觉得更安全。即使对于单行，这些都是简单的符号，可以轻松防止错误。它使代码更具可读性，因为您可以清楚地看到块中的内容，而不是将块的主体与块外的以下语句混淆。
如果我有一个单行，我通常将其格式化如下：
if( some_condition ) { do_some_operation; }
如果该行太麻烦，请使用以下内容：
if( some_condition )
{
do_some_operation;
}
答案 30 :(得分：2)
结合了两全其美的另一种方法是：
if(foo)
{DoSomething();}
如果线被注释掉，或者在它下面添加了另一条线，这可以避免任何混淆。
此外，我们使用MISRA-C作为编码标准，这要求所有类似的结构在所有情况下都使用大括号。
答案 31 :(得分：2)
答案 32 :(得分：2)
他们告诉你，因为他们仍然使用古代或通用（非语言感知）源代码编辑器。 如果你使用带有自动缩进的编辑器，那么你永远不会犯错，而且一直使用大括号可以避免这种错误。
答案 33 :(得分：1)
我曾经讨厌过牙箍。直到有一天我找到了他们的用途。我在不同的平台上工作，将应用程序从平台移植到平台（总共工作6个）。在UNIX上，如果安装了vim，则可以通过按“Shift + 5”轻松跳转到代码块的结尾或开头。这些主要是if / else块或循环。
所以，如果我在vim上查看Rampion的问题，我会完全迷失，并且需要一段时间才能完全理解代码。
答案 34 :(得分：1)
如果他/她为应用添加逻辑，您的维护程序员可能会忘记稍后添加大括号。所以发生以下情况：
if(foo)
bar();
bar(delete);
而不是
if(foo) {
bar();
}
bar(delete);
答案 35 :(得分：1)
我不认为省略括号总是不好的做法，但是是否应该允许并且在什么情况下必须在团队中达成一致。
我觉得这很可读： -
if (foo)
bar();
和这： -
if (foo)
bar()
else
snafu();
如果为这些添加额外的行： -
if (foo)
bar();
snafu();
这看起来都错了，有一段代码，缩进。但没有支撑。
类似的参数适用于for循环。但是，当我开始嵌套时： -
if (foo)
if (bar)
snafu()
现在我遇到了麻烦，看起来像是一块陈述。就个人而言，我只会跳过一个级别的括号，只有更深层次才能使外部代码使用大括号： -
if (foo) {
if (bar)
snafu()
}
当我输入这个时，我已经看到答案从1跳到17，显然这是一个情绪化的问题（我建议你在标签列表中添加主观性（我做这个的能力已经不见了）那个？））。
最重要的是在团队中就是否以及如何接受并坚持下去达成协议。
答案 36 :(得分：1)
我认为这一切都归结为偏好和可读性。通常添加花括号将使您的代码更具可读性，因为实际行与代码之间有额外的空间。另外，请考虑此示例（不是故意缩进）：
if (condition1)
if (condition2)
doSomething();
else
doSomethingElse();
doSomethingElse什么时候被调用？当condition1为true但condition2为false，或者condition1为false时？添加花括号可以快速解决这个可读性问题并避免混淆。
答案 37 :(得分：1)
缩进与大括号的使用无关。
某些编码风格并非如此。在我工作的地方，公司的编码标准允许我们在没有严格必要的情况下不用括号;然而，编码标准使我们缩进括号以及它们中的内容，所以我们最终得到这样的东西：
if (something)
{
for (i = 0; i < count; i++)
{
foo();
}
}
没有括号，这就变成了：
if (something
for (i = 0; i < count; i++)
foo();
使用这种编码风格，当有深度嵌套，连同长变量和函数名称并且你总是使用大括号时，你要么从屏幕右侧获得大量代码，要么大量换行，两者都是其中，IMO使代码读取或调试变得麻烦。出于这个原因，每当我能够逃脱时，我总是倾向于把括号留下来。
至于将单一声明与if放在同一行，有些公司的编码标准（包括我们的）禁止这样做，所以它并不总是一种选择。
如果是我的选择，我会更改公司编码标准，使大括号与if，for等等级相同，并在主体中与开口大括号相同的第一行（或注释），因此：
if (something)
{ for (i = 0; i < count; i++)
{ foo();
}
}
我更愿意（并且更有可能）总是使用大括号（甚至可以支持'总是使用大括号'规则），因为每对大括号只会增加一个大括号线条没有缩进，使其几乎与没有牙箍一样紧凑。
答案 38 :(得分：1)
if ( any ) {
DoSomething();
}
if ( any ) { DoSomething(); }
如果你认为，在一行中读得不那么好，你可以用两行写出来：
if ( any ) {
DoSomething(); }
if ( any )
{ DoSomething(); }
答案 39 :(得分：0)
这是一种交易，更短的代码（更易读）与更安全的代码（更不容易出错）。
我的2美分：
答案 40 :(得分：0)
我总是使用花括号，除了最内层的语句，假设最内层的语句是单行。所以我的代码看起来像：
for (int i=0; i<10; i++)
{
for (int x=0; x<20; x++)
{
if (someBoolValue)
DoThis(x,y);
}
}
另一个例外当然是使用语句堆叠。
写作绝对没有意义
using (Stream x = File.Open(...))
{
using (Stream y = File.Create(...))
{
...
}
}
什么时候可以写
using (Stream x = File.Open(...))
using (Stream y = File.Create(...))
{
....
}
答案 41 :(得分：0)
一方面，我将括号留下来进行单一陈述。另一方面，我用PC-Lint（http://www.gimpel.com/）检查所有C代码，它将if（）语句后面的两个或多个缩进行标记为“可疑缩进”。
顺便说一句，将单个语句放在与if（）相同的行上看起来是个好主意。
答案 42 :(得分：0)
我也喜欢更紧凑的格式。这就是我经常按Ctrl + K，Ctrl + D在Visual Studio中重新格式化的原因。我希望我能在每次按键后为我做这件事。
答案 43 :(得分：0)
当我看到“这种风格节省空间”时，我总是感到困惑
由于我很少（如果有的话）打印出代码，空间增益对我来说没有明显的优势：在磁盘上保存一些字节是不值得的，而且我不支付屏幕上占用的空间。
有些人发现紧凑的代码更具可读性，我不会争辩这个（非常主观），但作为业余艺术家和版画，我非常看重空白使用......
我不会重复上述论点，但我会补充说，我认为，一致性：我不喜欢像
这样的代码if (foo)
{
// Lot of code
}
else
DoStuff();
话虽如此，有时候我没有大括号：在守卫条件下，当我提前退出时：
if (somethingBadHappened)
return;
总而言之，我认为（几乎）系统地添加重要代码可以提高可读性（代码“呼吸”，并不局促），一致性，并且可能避免一些愚蠢的错误（是的，这种错误很明显，但是编码器是人（通常），可能是累，新手，压力......）。
我已经为SciTE创建了一个Lua宏，可以在任何代码块或当前行周围添加这些大括号，只需一次击键和正确的缩进：它对我来说真的没什么代价。
现在，如果你选择省略这些括号，我不会起诉你。正如其他人所指出的，可以在编码规则中设置一个选项或另一个选项。他们各自拥有。
答案 44 :(得分：0)
因为StyleCop这么说。
答案 45 :(得分：0)
如果您觉得“有时”使用大括号是有用的，那么您应该远离添加大括号。 程序应编写为由非计算机的人阅读。 我更喜欢括号：
if (mybool)
{
doMyStuff();
}
else
{
doMyOtherStuff();
checkStuff();
}
并不喜欢
if (mybool) {
doMyStuff();
}
else {
doMyOtherStuff();
checkStuff();
}
而不喜欢
if (mybool)
doMyStuff();
else
{
doMyOtherStuff();
checkStuff();
}
答案 46 :(得分：0)
另外，如果您要删除/不使用大括号来保存行，则需要重构代码。
答案 47 :(得分：0)
好吧，在我看来，这对我来说更像是个人偏好。我注意到，为了便于阅读，最好让{}然后没有它们。我注意到使用ReSharper，ReSharper倾向于删除它们并且如果这样的语句那么做你们大多数人
if(this == yes)
DoSomething();
但为了便于阅读，我总是这样做
if(this == yes)
{
DoSomething();
}
虽然在“if”语句中只有一行代码可读性并不是真的不同但是如果你在一个if语句中放入20-30行代码，那么使用{}就可以更容易地阅读它并且它会留下更少的空间错误和代码中的错误。
答案 48 :(得分：-1)
在大多数情况下我更喜欢大括号。通常，您会回到代码中添加更多行代码，无论如何都必须添加它们。
答案 49 :(得分：-1)
这里有很多很好的答案，为什么你不应该这样做 - 而且我也同意你不应该忽略大括号。
如果您正在寻找更简洁的代码，我实际上会使用三元语句。它们提供紧凑性和一定程度的明确性，并且更能抵抗事故。
如上所述，省略大括号的问题是事后错误的可能性。大多数程序员都同意他们可以阅读：
if( foo )
bar();
当人们来改变陈述并且不注意时，问题就出现了。在我工作的最后一个地方，实际上存在一个问题，这个问题是由某人修改声明或注释掉一行而引起的。制定了一个编码标准，以确保这样的错误再也不会发生。
正如其他人所说，程序员的时间是昂贵的。就像评论你的代码一样，通常省略比特因为它们是可选的，但易于维护的代码通常依赖于那些“可选”的东西。
最后，有些人提到现代编辑器和IDE应该自动缩进并自动显示范围。我的答案是不要使用拐杖这样的东西。有时您从源存储库或远程连接甚至电子邮件中查看代码 - 这些都是开发的现实。您可能没有IDE或高级编辑器来向您显示您的错误。始终编写代码，以便无论您加载什么内容都可以理解。
答案 50 :(得分：-1)
您是否考虑过针对单行if else语句探索此选项：
(!a) ? Foo() : Bar();
答案 51 :(得分：-2)
AFAIR花括号总是一个范围，所以每次都可以使用它们。
没有大括号：
if(DoSomething)
MyClass myClass = new MyClass();
myClass.DoAnythingElse();
这将编译，但很容易导致空引用。 （C＃编译器不编译这个，好东西！）
然而这样：
if(doSomething)
{
MyClass myClass = new MyClass();
}
myClass.DoAnythingElse();
甚至不会编译。
远比在编译时最小化异常要好，而不是在运行时找到它们。