### 为什么省略花括号被认为是一种不好的做法？

``````if (foo)
Bar();

//or

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

``````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));
``````

``````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 (foo)
Bar();
Biz();
``````

### 问题：

1. 想要使用语言提供的更紧凑的语法是错误的吗？设计这些语言的人很聪明，我无法想象他们会提出一个总是不好用的功能。
2. 我们是否应该编写代码，以便最低的共同分母可以理解并且使用它没有任何问题？
3. 我还缺少另一个论点吗？

#### 52 个答案:

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

``````if(foo) bar();
``````

``````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(a)
if(b)
c();
else
d();
``````

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

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

（a）任何其他开发人员都可以轻松地遵循我正在做的事情

（b）评论可能需要它的代码的特定部分

（c）如果出现问题，可以轻松调试

（d）如果将来需要（即添加/删除代码），则易于修改

``````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
}
``````

`````` 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();
``````

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

``````#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)
``````

``````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();
``````

VS

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

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

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

• 我的编辑器为我自动格式化，因此我因缩进误导的可能性大大降低。

• TDD 意味着如果我引入了一个错误，因为我对单行块感到困惑，我更有可能快速发现错误。

• 重构和语言表达意味着我的块更短，并且单行块的发生频率比使用时更频繁。假设有一个无情的ExtractMethod应用程序，我可能在整个程序中只有 单行块。 （我想知道那会是什么样的？）

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

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

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

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

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

bug咬我（或者更确切地说是“我和同事” - 我实际上没有介绍这个错误）一次。尽管我们当时的编码标准建议在任何地方使用括号。我花了很长时间才发现 - 因为你看到了你想要看到的东西。 （这是大约10年前的事。也许我现在发现它更快。）

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

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

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

• 如果所有if语句都以统一的方式编写，我会发现它更容易阅读。
• 它可能使软件更健壮，没有bug。然而，所有现代IDE和高级文本编辑器都有很好的自动缩进功能，我认为每个人都应该使用它，只要它不会弄乱注释格式或违反团队标准（在很多情况下，可以创建自定义格式化方案）并与团队分享）。我的观点是，如果正确完成缩进，可以减少bug引入的风险。
• 我更喜欢将布尔表达式和语句执行到不同的行。我希望能够为调试目的标记一行。即使我正在使用IDE，我可以在其中标记语句并继续它，它是一个交互式操作，我可能忘记了我开始调试的地方，或者至少我需要花费更多的时间来完成代码的几个步骤时间（因为我必须在调试期间每次手动标记位置）。

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

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

``````if (foo) bar();
``````

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

``````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();
``````

``````if (foo)
bar();
``````

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

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

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

``````if (foo)
bar();
``````

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

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

Err更安全 - 只有一个你可能无需修复的bug。

``````if( some_condition ) { do_some_operation; }
``````

``````if( some_condition )
{
do_some_operation;
}
``````

``````if(foo)
{DoSomething();}
``````

1. 空白是免费的。
2. 取决于缩进以便将来阅读，这取决于标签设置，这不是一个好主意。曾经使用过10年没有修改版本的代码吗？
3. 我的经验是，任何时候通过不输入花括号而节省下来的时间都会因为花费额外的时间而弄清楚你的意思。

``````if (something)
{
for (i = 0; i < count; i++)
{
foo();
}
}
``````

``````if (something
for (i = 0; i < count; i++)
foo();
``````

``````if (something)
{ for (i = 0; i < count; i++)
{ foo();
}
}
``````

``````if(foo)
bar();
bar(delete);
``````

``````if(foo) {
bar();
}
bar(delete);
``````

• 将打开的括号写在与前一个语句相同的行上：

``````if ( any ) {
DoSomething();
}
``````

• 如果你认为，这太大了，你     可以写成一行：

``````if ( any ) { DoSomething(); }
``````

如果你认为，在一行中读得不那么好，你可以用两行写出来：

``````if ( any ) {
DoSomething(); }
if ( any )
{ DoSomething(); }
``````
• 将来有人需要改变 一个声明更多的陈述。 没有括号就是更改 复杂。是的，只有一点点，但是 更好地防止错误。并写作 括号很容易便宜。
• 答案 36 :(得分：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，显然这是一个情绪化的问题（我建议你在标签列表中添加主观性（我做这个的能力已经不见了）那个？））。

最重要的是在团队中就是否以及如何接受并坚持下去达成协议。

答案 37 :(得分：1)

我曾经讨厌过牙箍。直到有一天我找到了他们的用途。我在不同的平台上工作，将应用程序从平台移植到平台（总共工作6个）。在UNIX上，如果安装了vim，则可以通过按“Shift + 5”轻松跳转到代码块的结尾或开头。这些主要是if / else块或循环。

所以，如果我在vim上查看Rampion的问题，我会完全迷失，并且需要一段时间才能完全理解代码。

答案 38 :(得分：1)

我认为这一切都归结为偏好和可读性。通常添加花括号将使您的代码更具可读性，因为实际行与代码之间有额外的空间。另外，请考虑此示例（不是故意缩进）：

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

doSomethingElse什么时候被调用？当condition1为true但condition2为false，或者condition1为false时？添加花括号可以快速解决这个可读性问题并避免混淆。

答案 39 :(得分：0)

当我看到“这种风格节省空间”时，我总是感到困惑 由于我很少（如果有的话）打印出代码，空间增益对我来说没有明显的优势：在磁盘上保存一些字节是不值得的，而且我不支付屏幕上占用的空间。
有些人发现紧凑的代码更具可读性，我不会争辩这个（非常主观），但作为业余艺术家和版画，我非常看重空白使用......

我不会重复上述论点，但我会补充说，我认为，一致性：我不喜欢像

这样的代码
``````if (foo)
{
// Lot of code
}
else
DoStuff();
``````

话虽如此，有时候我没有大括号：在守卫条件下，当我提前退出时：

``````if (somethingBadHappened)
return;
``````

总而言之，我认为（几乎）系统地添加重要代码可以提高可读性（代码“呼吸”，并不局促），一致性，并且可能避免一些愚蠢的错误（是的，这种错误很明显，但是编码器是人（通常），可能是累，新手，压力......）。

我已经为SciTE创建了一个Lua宏，可以在任何代码块或当前行周围添加这些大括号，只需一次击键和正确的缩进：它对我来说真的没什么代价。

现在，如果你选择省略这些括号，我不会起诉你。正如其他人所指出的，可以在编码规则中设置一个选项或另一个选项。他们各自拥有。

答案 40 :(得分：0)

这是一种交易，更短的代码（更易读）与更安全的代码（更不容易出错）。

我的2美分：

1. 这条规则有原因。它是由无数程序员通过长时间工作开发的，一直延续到夜晚或第二天早上，试图修复由于一点点疏忽造成的错误。
2. 如果交易是值得的，你不能自己决定。
3. 根据我的经验，我是那些无数程序员之一，他们一直在努力寻找一个令人讨厌的bug的原因。原因是我很懒惰。

答案 41 :(得分：0)

我也喜欢更紧凑的格式。这就是我经常按Ctrl + K，Ctrl + D在Visual Studio中重新格式化的原因。我希望我能在每次按键后为我做这件事。

答案 42 :(得分：0)

一方面，我将括号留下来进行单一陈述。另一方面，我用PC-Lint（http://www.gimpel.com/）检查所有C代码，它将if（）语句后面的两个或多个缩进行标记为“可疑缩进”。

顺便说一句，将单个语句放在与if（）相同的行上看起来是个好主意。

答案 43 :(得分：0)

因为StyleCop这么说。

答案 44 :(得分：0)

如果您觉得“有时”使用大括号是有用的，那么您应该远离添加大括号。 程序应编写为由非计算机的人阅读。 我更喜欢括号：

``````if (mybool)
{
doMyStuff();
}
else
{
doMyOtherStuff();
checkStuff();
}
``````

并不喜欢

``````if (mybool) {
doMyStuff();
}
else {
doMyOtherStuff();
checkStuff();
}
``````

而不喜欢

``````   if (mybool)
doMyStuff();
else
{
doMyOtherStuff();
checkStuff();
}
``````

答案 45 :(得分：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(...))
{
....
}
``````

答案 46 :(得分：0)

另外，如果您要删除/不使用大括号来保存行，则需要重构代码。

答案 47 :(得分：0)

好吧，在我看来，这对我来说更像是个人偏好。我注意到，为了便于阅读，最好让{}然后没有它们。我注意到使用ReSharper，ReSharper倾向于删除它们并且如果这样的语句那么做你们大多数人

``````if(this == yes)
DoSomething();
``````

但为了便于阅读，我总是这样做

``````if(this == yes)
{
DoSomething();
}
``````

虽然在“if”语句中只有一行代码可读性并不是真的不同但是如果你在一个if语句中放入20-30行代码，那么使用{}就可以更容易地阅读它并且它会留下更少的空间错误和代码中的错误。

答案 48 :(得分：-1)

这里有很多很好的答案，为什么你不应该这样做 - 而且我也同意你不应该忽略大括号。

如果您正在寻找更简洁的代码，我实际上会使用三元语句。它们提供紧凑性和一定程度的明确性，并且更能抵抗事故。

如上所述，省略大括号的问题是事后错误的可能性。大多数程序员都同意他们可以阅读：

``````if( foo )
bar();
``````

当人们来改变陈述并且不注意时，问题就出现了。在我工作的最后一个地方，实际上存在一个问题，这个问题是由某人修改声明或注释掉一行而引起的。制定了一个编码标准，以确保这样的错误再也不会发生。

正如其他人所说，程序员的时间是昂贵的。就像评论你的代码一样，通常省略比特因为它们是可选的，但易于维护的代码通常依赖于那些“可选”的东西。

最后，有些人提到现代编辑器和IDE应该自动缩进并自动显示范围。我的答案是不要使用拐杖这样的东西。有时您从源存储库或远程连接甚至电子邮件中查看代码 - 这些都是开发的现实。您可能没有IDE或高级编辑器来向您显示您的错误。始终编​​写代码，以便无论您加载什么内容都可以理解。

答案 49 :(得分：-1)

您是否考虑过针对单行if else语句探索此选项：

``````(!a) ? Foo() : Bar();
``````

答案 50 :(得分：-1)

在大多数情况下我更喜欢大括号。通常，您会回到代码中添加更多行代码，无论如何都必须添加它们。

答案 51 :(得分：-2)

AFAIR花括号总是一个范围，所以每次都可以使用它们。

没有大括号：

``````if(DoSomething)
MyClass myClass = new MyClass();

myClass.DoAnythingElse();
``````

这将编译，但很容易导致空引用。 （C＃编译器不编译这个，好东西！）

然而这样：

``````if(doSomething)
{
MyClass myClass = new MyClass();
}

myClass.DoAnythingElse();
``````

甚至不会编译。

远比在编译时最小化异常要好，而不是在运行时找到它们。

相关问题
最新问题