为什么省略大括号被认为是不好的做法?

为什么每个人都告诉我编写这样的代码是一种糟糕的做法?

if (foo)
Bar();


//or


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

省略大括号的最大理由是,有时候大括号的行数可能是大括号的两倍。例如,下面的一些代码用于在 C # 中为标签绘制辉光效果。

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

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

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

大括号最常见的参数围绕着维护编程,以及在原始 if 语句和它的预期结果之间插入代码会带来的问题:

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

问题:

  1. 希望使用语言提供的更紧凑的语法是错误的吗?设计这些语言的人很聪明,我无法想象他们会把一个总是不好用的特性放进去。
  2. 我们是否应该编写代码以便最小公分母能够理解并且使用时没有问题?
  3. 我还漏掉了什么论点吗?
65117 次浏览

假设你有一些代码:

if (foo)
bar();

然后另一个人过来补充道:

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

根据其编写方式,bar () ; 现在无条件执行。通过包含花括号,可以防止此类意外错误。编写代码的方式应该使这种错误难以犯或不可能犯。如果我正在做一个代码检查,看到缺少的大括号,尤其是分布在多个行中,我会创建一个缺陷。在合理的情况下,将其保持在一行上,以便再次将出现这种错误的可能性保持在最低限度。

你的维护程序员可能忘记添加花括号后,如果他/她添加逻辑的应用程序。所以下面的事情发生了:

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

而不是

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

总会有例外,但是我不赞成只有在以下形式之一的情况下才省略大括号:

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


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

否则,我没有问题。

事实上,唯一一次真正困扰我的是我在调试的时候,注释掉 bar () :

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

除此之外,我倾向于使用:

if(foo) bar();

这就解决了上面的问题。

谢谢你澄清了这个问题,我同意,我们不应该给最小公分母写代码。

我偶尔使用最底部的代码(多个 using 语句) ,但除此之外,我总是使用大括号。我只是觉得这样代码更清晰。很明显,不仅仅是缩进,语句还是块的一部分(因此可能是 if 等的一部分)。

我见过

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

臭虫咬我(或者更确切地说是“我和同事们”——实际上我并没有介绍臭虫)。尽管我们当时的编码标准建议在任何地方都使用大括号,但实际情况却是如此。我花了很长时间才发现——因为你看到的是你想看到的。(这是大约10年前的事了。也许我现在能更快找到它。)

当然,如果您使用“ brace at the end Of the line”,它会减少额外的行,但我个人不喜欢这种风格。(我在工作时使用它,发现它没有我想象的那么不舒服,但还是有点不舒服。)

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

最终,其他人将需要理解您的代码,这是一个主要的时间消耗,每个开发人员必须弄清楚他们正在处理的代码部分的具体风格。

另外,想象一下,有人每天不止一次在 Python 和 Cish 语言之间切换... ... 在 Python 中,缩进是语言块语义的一部分,很容易出现你引用的那种错误。

其中一个主要问题是,当您有一行程序和非一行程序的区域时, 随着从控制语句(forif,你有什么)的分离和语句的结束。

例如:

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
}

我同意这样的观点: “如果你足够聪明,能让别人付钱让你写代码,那么你就应该足够聪明,不要仅仅依赖缩进来查看代码的流程。”

然而... 错误是可能发生的,而且这个错误调试起来很痛苦... 特别是当你查看别人的代码的时候。

与更安全的代码(更不容易出错)相比,它是一种交易,代码更短(可读性更好)。

我的建议是:

  1. 这个规则是有原因的。它是由无数程序员通过长时间的工作开发出来的,一直工作到晚上或者第二天早上,试图修复一个由一点小疏忽引起的 bug。
  2. 你必须自己决定这笔交易是否值得。
  3. 根据我的经验,我是无数程序员中的一员,他们夜以继日地工作,寻找一个讨厌的 bug 的原因。原因是我太懒了。

为了避免大括号代码占用大量空间,我使用了 代码完成一书中推荐的技术:

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

我总是在适当的时候省略它们,比如在你的第一个例子中。简洁明了的代码,我可以通过浏览来看到和理解,这比我必须一行一行地滚动和阅读的代码更容易维护、调试和理解。我认为大多数程序员都会同意这一点。

如果您开始执行多个嵌套、 if/else 子句等等操作,那么很容易失控,但是我认为大多数程序员应该能够知道在哪里画线。

我觉得这有点像 if ( foo == 0 )if ( 0 == foo )的争论。后者可以防止新程序员出现错误(甚至可能偶尔对老程序员出现错误) ,而前者在维护代码时更容易快速阅读和理解。

反对使用大括号的主要理由是它们使用了额外的行,并且需要额外的缩进。

行(几乎)是空闲的,最小化代码中的行数不应该是目标。

缩进与括号的使用无关。在级联“ using”示例中,我仍然认为应该缩进它们,即使省略了大括号。

我曾经是一个巨大的支持者“花括号是必须的!”,但是由于采用了单元测试,我发现我的单元测试保护无括号语句不受以下场景的影响:

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

通过良好的单元测试,我可以自信地省略简单语句的大括号,以提高可读性(是的,这可能是主观的)。

或者,对于类似上面的内容,我可能会内嵌这样的内容:

if (foo) snafu();

这样,需要在条件中添加 bar ()的开发人员就更容易发现没有大括号,然后添加它们。

如果是很小的东西,就这样写:

if(foo()) bar();

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

我更喜欢花括号提供的清晰度。您完全知道这意味着什么,并且不需要猜测是否有人只是出了差错而没有关闭它们(并且引入了 bug)。我唯一省略它们的时候是将 if 和 action 放在同一行中。我也不经常这么做。实际上,我更喜欢将花括号放在自己的行上而引入的空格,尽管经过多年类似于 K & R C 的编程,如果 IDE 不强制我使用花括号结束这一行,那么我必须克服这种做法。

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


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

我的哲学是,如果它使代码更易读,为什么不这样做呢?

显然,您必须在某个地方划清界限,比如在简洁和过度描述性的变量名之间找到一个令人满意的中间位置。但是括号确实可以避免错误并提高代码的可读性。

你可以争辩说,聪明到足以成为程序员的人也会聪明到足以避免那些干扰无括号语句的 bug。但是你能诚实地说你从来没有被一个简单的拼写错误绊倒过吗?像这样的细枝末节在看到大型项目时会让人不知所措。

  • 在前面的语句的同一行上写上开括号:

    if ( any ) {
    DoSomething();
    }
    

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

    if ( any ) { DoSomething(); }
    

    如果你觉得一行不太好读,你可以写成两行:

    if ( any ) {
    DoSomething(); }
    if ( any )
    { DoSomething(); }
    
    • 将来有人需要改变 一个陈述换更多陈述。 没有括号的更改更多 复杂。是的,只有一点点,但是 是更好地防止错误。和写 托架是一种非常简单廉价的方法。
  • 这并不总是被认为是一种不好的做法。Mono 项目编码指南建议,如果没有必要,不要使用花括号。GNU 编码标准也一样。我认为这是个人品味的问题,因为编码标准总是如此。

    我不认为省略大括号总是一个不好的做法,但是是否应该被允许,以及在什么情况下必须在团队中达成一致。

    我觉得这非常可读:-

    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,很明显这将是一个情绪化的问题(我建议你在标签列表中加入主观因素(我做这件事的能力已经丢失了,那又怎么样呢?)).

    最重要的事情是在团队中达成一致,如果以及如何接受并坚持下去。

    AFAIR 花括号总是一个范围,因此,它是好使用他们每次。

    没有牙套:

    if(DoSomething)
    MyClass myClass = new MyClass();
    
    
    myClass.DoAnythingElse();
    

    这将编译,但导致空引用容易。(C # 编译器不编译这个,好事!)

    而这种方式:

    if(doSomething)
    {
    MyClass myClass = new MyClass();
    }
    
    
    myClass.DoAnythingElse();
    

    都不会编译。

    这比在编译时减小异常要好得多,比在运行时查找异常要好得多。

    我认为这是你正在做的项目的指导方针和个人品味的问题。

    我通常会在不需要的时候省略它们,除了下面这些情况:

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

    我更喜欢

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

    这个问题可能会困扰你的一个例子是回到过去的 C/C + + 宏时代。我知道这是一个 C # 问题,但是编码标准经常在没有标准最初创建原因的情况下继续执行。

    如果在创建宏时不够小心,可能会导致 If 语句没有使用{}而出现问题。

    #define BADLY_MADE_MACRO(x) function1(x); function2(x);
    
    
    if (myCondition) BADLY_MADE_MACRO(myValue)
    

    现在,不要误会我的意思,我并不是说你应该总是这样做,只是为了在 C/C + + 中避免这个问题,但是我不得不处理一些非常奇怪的错误,因为这个。

    更安全的方面的错误-只是一个错误,您可能不必修复。

    我个人觉得,如果我所有的积木都包在卷曲更有安全感。即使对于一行程序来说,这些简单的标记也很容易避免错误。它使代码更具可读性,因为可以清楚地看到块中的内容,不会将块的主体与块外的以下语句混淆。

    如果我有一个一行程序,我通常会将其格式化如下:

    if( some_condition ) { do_some_operation; }
    

    如果线条过于繁琐,请使用以下内容:

    if( some_condition )
    {
    do_some_operation;
    }
    

    好吧,在我看来,这更多的是我个人的偏好。然而,我注意到对于可读性来说,有{}总比没有好。我已经注意到使用 ReSharper,ReSharper 倾向于删除它们,如果这样的语句,大多数人都会这样做

    if(this == yes)
    DoSomething();
    

    但是为了可读性,我总是这样做

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

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

    我也曾经认为只在真正需要的时候使用大括号更好。但现在不一样了,主要原因是,当你有很多代码时,它确实使代码更具可读性,当你有一个一致的括号样式时,你可以更快地解析代码。

    另一个经常使用大括号的好理由是,除了有人在 if 中添加了第二个语句之外,可能会发生类似的情况:

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

    你有没有注意到 else 子句实际上是 if (b)的?你可能知道,但你会相信任何熟悉这个陷阱的人吗?

    所以,如果只是为了保持一致性,并且因为你永远不知道当 别人(总是其他人愚蠢)改变代码时会发生什么意想不到的事情,我总是放大括号,因为它使源代码更易读,更快地被你的大脑解析。只有对于最简单的 if 发言,比如代表团成立的 if 或者类似于 switch 的 if,你知道该条款永远不会被延长,我才会省略括号。

    你有没有想过探索这个单行 if else 语句的选项:

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

    我坚信编写简洁明了的代码,但我总是使用大括号。我发现它们是快速查看特定代码行所在范围的一种方便方法。没有模棱两可,它只是明确地展现在你面前。

    有些人可能会说这是一种偏好,但是我发现如果程序内部是一致的,那么它的逻辑流程就更容易遵循,而且我不认为像这样编写一个 IF 语句是一致的;

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

    还有一个这样的

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

    我更喜欢只选择一种通用的风格,并坚持下去:)

    当我看到“这种款式节省空间”时,我总是感到困惑。
    由于我很少(如果有的话)打印出代码,因此增加空间对我来说没有明显的好处: 在磁盘上节省一些字节不值得,而且我也不会为屏幕上占用的空间付费。
    有些人发现紧凑的代码更易读,我不会否认这一点(高度主观) ,但作为业余艺术家和排版,我高度重视空白的使用..。

    我不会重复上面的论点,但是我会补充,我认为,一致性: 我不喜欢这样的代码

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

    话虽如此,有时我还是不戴牙套: 在警卫的情况下,当我提前离开的时候:

    if (somethingBadHappened)
    return;
    

    总而言之,我认为在重要代码周围添加(几乎)系统性的大括号可以提高可读性(代码“喘息”,不拥挤) ,一致性,并可能避免一些愚蠢的错误(是的,这种错误是显而易见的,但编码者是人类(通常) ,可以累,新手,在压力下...)。

    我为 SciTE 做了一个 Lua 宏,在任何代码块或当前行周围添加这些大括号,只需一次击键和正确的缩进: 它对我来说真的没有任何成本。

    如果你不戴牙套,我就不起诉你。正如其他人指出的那样,可以在编码规则中设置一个或另一个选项。各有所爱。

    减少直线并不是去掉大括号的好理由。如果您的方法太大,可能应该将其重构成更小的部分或重新构造。这样做无疑会提高可读性,而不仅仅是去掉大括号。

    线路很便宜。处理器电源很便宜。开发人员的时间非常昂贵。

    一般来说,除非我正在开发一些绝对重要的资源/速度应用程序,否则我总是会在编写代码时犯错

    (a)容易让其他发展商跟随我的做法

    (b)对代码中可能需要注释的具体部分进行注释

    (c)出错时容易调试

    (d)日后如有需要,可轻易修改(即加入/删除代码)

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

    通过在大多数情况下省略大括号,对我来说(b)、(c)和(d)变得更加困难(注意不是不可能)。我认为使用花括号或不使用花括号对(a)没有影响。

    一方面,我为一个语句省略了大括号。另一方面,我使用 PC-Lint (http://www.gimpel.com/)检查所有 C 代码,它将 if ()语句后面的两行或多行缩进标记为“可疑缩进”。

    顺便说一下,把单个语句放在 if ()的同一行上看起来是个不错的主意。

    我对我在计算机编程领域的同行(你们这些人)没有因为跳过单行代码块上的大括号可能出现的 bug 而感到气馁,这给我留下了深刻的印象。

    我想这意味着我不聪明。我在这件事上已经犯过很多次错误了。我已经调试了别人在这方面的错误。我曾经看到过软件因为这个而出现 bug (RDP 到一台运行 VS2002的机器上,你的手表窗口字体会变得不稳定)。

    如果我看看所有我犯过的错误,这些错误本可以通过改变编码风格来避免,这个列表非常长。如果我没有在这些情况下改变我的方法,我可能永远不会成为一个程序员。再说一次,我想我不够聪明。作为补偿,我长期以来一直是单行代码块上大括号的忠实用户。

    也就是说,世界上的一些事情已经发生了变化,使得“你应该在单行方块上使用括号”的规则在今天变得不像摩西给我们讲的那样重要了:

    • 一些流行的语言通过让计算机读取缩进来解决这个问题,就像程序员所做的那样(例如 Python)。

    • 我的编辑 自动格式化为我,所以我的机会被误导的缩进很大程度上减少了。

    • TDD 意味着,如果我因为被一个单行代码块搞糊涂而引入了一个 bug,那么我更有可能很快发现这个 bug。

    • 重构和语言表达能力 意味着我的代码块要短得多,而且单行代码块的出现频率要比以前高得多。假设,如果无情地应用了萃取方法,我可能会在整个程序中使用 只有单行块。(我想知道那会是什么样子?)

    事实上,在单行代码块上无情地重构和省略大括号有一个明显的好处: 当你看到大括号的时候,你的脑海中会响起一个小小的警报,说“这里很复杂!小心!”.想象一下,如果这是常态:

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

    我打算把我的编码惯例改成“单行代码块可能永远不会有大括号”或者“如果你可以把代码块和条件放在同一行上,并且都在80个字符之内,那就省略大括号”。走着瞧吧。

    我总是使用大括号,除了内部的 most 语句,假设内部的 most 语句是单行语句。我的代码是这样的:

    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(...))
    {
    ....
    }
    

    保罗表示:

    缩进与括号的使用无关。

    对于某些编码风格来说,情况并非如此。在我工作的地方,公司的编码标准允许我们不使用大括号,如果它们不是严格必要的; 然而,编码标准要求我们缩进大括号,以及它们中的内容,所以我们最终得到了这样的东西:

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

    如果没有牙套,就会变成:

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

    有了这种编码风格,当有深嵌套,加上长变量和函数名,你总是使用大括号,你要么得到大量的代码去右边的屏幕或很多行包装,这两者,我的天,使代码阅读或调试麻烦。出于这个原因,我总是倾向于在任何我可以逃脱这样做的时候把牙套留在外面。

    至于把一条语句和 if 放在同一行,一些公司的编码标准(包括我们的)禁止这样做,所以这并不总是一个选项。

    如果是我的选择,我会改变公司的编码标准,使用大括号级别的 If、 for 等,并在主体中的第一行(或注释)与开头的大括号在同一行上,因此:

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

    我会更愿意(也更有可能)总是使用大括号(甚至会支持“总是使用大括号”的规则) ,因为每对大括号只会增加一行额外的内容,而且不会有缩进,使得它几乎和没有大括号一样紧凑。

    三大公约中:

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

    以及:

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

    和(表示使用开括号和闭括号的任何缩进样式) :

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

    我更喜欢最后一个:

    • 我发现如果所有的 if 语句都以统一的方式编写,那么读起来会更容易。
    • 它可能会使软件更加健壮和没有错误。然而,所有现代 IDE 和高级文本编辑器都有很好的自动缩进功能,我认为每个人都应该使用这些功能,只要它不会搞乱注释格式或违背团队标准(在很多情况下,可以创建一个自定义格式方案并与团队共享)。我的观点是,如果缩进做得正确,引入错误的风险就会减少一点。
    • 我更喜欢在不同的行上执行布尔表达式和语句。我希望能够为了调试的目的而标记一行。即使我使用 IDE 来标记语句并逐步执行它,它也是一个交互式操作,我可能会忘记我从哪里开始调试,或者至少我需要多花一点时间来逐步执行代码几次(因为我必须在每次调试期间手动标记位置)。

    阅读速度..。

    除了之前提到的。此时,我已经习惯于解析带大括号和空格的 if 语句。所以我读到:

    if (condition)
    {
    DoSomething();
    }
    
    
    DoSomethingElse();
    

    比我读到的要快一点:

    if (condition) DoSomething();
    
    
    DoSomethingElse();
    

    如果是这样的话,我会读慢一点:

    if (condition) DoSomething();
    DoSomethingElse();
    

    我读这篇文章的速度明显比之前的慢:

    if (condition)
    DoSomething();
    DoSomethingElse();
    

    因为为了以防万一,我忍不住又读了一遍,想知道作者是否有意:

    if (condition)
    {
    DoSomething();
    DoSomethingElse();
    }
    

    已经涵盖了一般,但当谈到 阅读的下面,我会看看这相当一段时间,以确保作者的意图。我甚至可以找到原作者来确认。

    if (condition)
    DoSomething();
    DoSomethingElse();
    

    我认为这一切都归结为偏好和可读性。通常,添加大括号会使代码更具可读性,因为实际的代码行之间有额外的空间。另外,考虑一下这个例子(不是刻意缩进的) :

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

    什么时候叫别的什么?条件1为真但条件2为假,或者条件1为假?添加大括号可以快速解决这个可读性问题,并避免混淆。

    结合两者优点的另一种方法是:

    if(foo)
    {DoSomething();}
    

    如果该行被注释掉,或者在它下面添加了另一行,这样可以避免任何混淆。

    另外,我们使用 MISRA-C作为编码标准,它要求所有类似的构造在所有情况下都使用大括号。

    大多数情况下我更喜欢戴牙套。通常,您会返回到代码来添加更多的代码行,而且无论如何都必须添加它们。

    这里有很多关于为什么不应该的好答案——我也同意你不应该省略大括号。

    如果你想要更简洁的代码,我会使用三元语句。它们提供了一定程度的紧凑性和明确性,并且对事故有更强的抵抗力。

    如前所述,省略大括号的问题在于事后出错的可能性。大多数程序员会同意他们可以阅读:

    if( foo )
    bar();
    

    问题来了,人们来了,改变了声明,并没有注意到。在我工作的最后一个地方,实际上有一个问题是由于某人修改了声明或注释了一行。我们制定了一个编码标准,以确保这样的错误不会再次发生。

    正如有人所说,程序员的时间是昂贵的位。就像注释代码一样,省略位通常更快,因为它们是可选的,但易于维护的代码通常依赖于那些“可选”的东西。

    最后,有些人提到现代编辑器和 IDE 应该自动缩进并显示范围。我的答案是不要把这些东西当作拐杖。有时候,当您从源代码库中查看代码,或者通过远程连接,甚至在电子邮件中查看代码时,这些就是开发的实际情况。您可能没有 IDE 或高级编辑器来告诉您哪里做错了。始终编写代码,以便无论加载什么代码都可以理解。

    我以前也讨厌牙套。直到有一天我发现它们有用。我在不同的平台上工作,将应用程序从一个平台移植到另一个平台(总共工作了6个平台)。在 UNIX 上,如果您已经安装了 vim,那么您可以通过按“ Shift + 5”轻松地跳转到代码块的结束或开始。这些主要是 if/else 块或循环。

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

    自己判断一下。

    if (foo)
    bar();
    

    除非你真的担心白痴之后会放这样的东西进来:

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

    如果您不担心白痴,那么没问题(我不担心——如果他们不能正确地使用基本的代码语法,这是他们最小的问题) >

    作为交换,它更易读。

    其余时间:

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

    从我记事起,这就是我最喜欢的。另外:

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

    我没问题。

    垂直空间本身并不重要,重要的是可读性。一行中的大括号本身只是停止了一个句法元素的对话,直到你的眼睛移动到下一行。我不喜欢这样。

    1. 空白是免费的。
    2. 为了将来的可读性而依赖缩进意味着依赖制表符设置,这不是一个好主意。有没有在不受修订控制的十年前的代码上工作过?
    3. 我的经验是,不输入花括号而节省下来的任何时间,都比我花费额外的时间来弄明白你的意思所浪费的时间要多。

    我也喜欢更紧凑的格式。这就是为什么我经常在 Visual Studio 中按 Ctrl + K,Ctrl + D 来重新格式化。我只是希望每次按键之后都能让它为我做这个。

    我以前也是这么想的。

    直到有一天(为什么总有那么一天会永远改变你的生活?)我们花了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();
    

    原来系统每天生成500mb 的日志,我们被要求停止它。调试标志不够,因此应该进行搜索和替换 println。

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

    编辑

    现在,我唯一不使用大括号的地方是在 if/try 结构中。

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

    在看到一个超级明星开发商这么做之后。

    好吧,这是一个老问题,已经回答了死亡。我有一些补充。

    首先我要说的是,使用牙套。它们只能帮助提高可读性和可读性(对于你自己和其他人!)应该是你优先考虑的事情,除非你在写汇编。不可读的代码总是,总是导致 bug。如果您发现大括号使代码占用了太多的空间,那么您的方法可能太长了。如果方法正确的话,任何方法的大部分或全部都应该适合于一个屏幕高度,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.
    }
    

    因为 StyleCop 是这么说的。

    如果你觉得“有时候”使用大括号是有用的,那么你应该一直使用大括号来保持一致。 程序应该写给人而不是计算机来读。 我更喜欢这样的牙套:

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

    而不是喜欢

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

    而不是喜欢

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

    另一方面,如果要删除/不使用大括号来保存行,则需要重构代码。

    他们告诉您是因为他们仍然使用古老的或通用的(不支持语言的)源代码编辑器。 如果您使用具有自动缩进的编辑器,那么您将永远不会犯一个错误,而这个错误本可以通过一直使用花括号来避免。

    坦率地说,我认为这是:

    好的程序员防御性地编程,而差的程序员则不会。

    由于上面有几个例子,而且我自己也有过类似的遗忘大括号的错误经历,所以我学到了“总是放大括号”的艰难之路。

    其他任何事情都是选择个人风格而不是安全,这显然是糟糕的编程。

    乔尔甚至在 让错误的代码看起来错误中提到了这一点

    一旦你因为缺少大括号而被 bug 咬了,你会发现缺少大括号看起来是错误的,因为你知道它可能是另一个 bug 发生的地方。

    我很乐意:

    foreach (Foo f in foos)
    foreach (Bar b in bars)
    if (f.Equals(b))
    return true;
    
    
    return false;
    

    就我个人而言,我不明白为什么

    foreach (Foo f in foos)
    {
    foreach (Bar b in bars)
    {
    if (f.Equals(b))
    {
    return true;
    }
    }
    }
    
    
    return false;
    

    更容易读懂。

    是的,行是免费的,但是为什么我必须滚动一页又一页的代码,因为它可以只有一半的大小?

    如果在可读性或可维护性方面存在差异,那么,当然,加上大括号... ... 但在这种情况下,我看不出有任何理由这样做。

    另外,我将 一直都是放大括号为嵌套的,如果是在我已经嵌套了别人的

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

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

    非常令人困惑,所以我总是这样写:

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

    只要有可能,我使用三元运算符,但我 永远不会 筑巢