【问题标题】:shall brackets be used for one line conditional statements? [closed]括号应该用于单行条件语句吗? [关闭]
【发布时间】:2012-11-08 11:12:00
【问题描述】:

除了可读性之外,在编写单行循环/条件语句时,带和不带括号在性能或编译时间上是否有任何差异?

例如,以下有什么区别:

if (a > 10) 
    a = 0;

if (a > 10)
{
    a = 0;
}

?

【问题讨论】:

标签: java c++ c


【解决方案1】:

当然在性能上没有区别。但是引入错误的可能性是有区别的:

if (a>10)
  a=0;

如果有人扩展代码并稍后编写,

if (a>10)
  a=0;
  printf ("a was reset\n");

由于缺少大括号,这将始终被打印。有些人要求你总是使​​用大括号来避免这种错误。

【讨论】:

【解决方案2】:

与几个答案相反,在编译时存在有限但可以忽略的性能差异。运行时任何类型的差异为零。

【讨论】:

  • 你能告诉我们那是多少有限吗?
  • @Pratik 不,我想我不能。 “微不足道”是我想去的最接近的地方。
【解决方案3】:

不,没有区别,编译器会去掉无意义的大括号、换行符等。

编译时间将略有不同,但如此微小,以至于您阅读此答案所花费的时间远远多于您恢复编译速度的时间。随着计算能力的提高,这一成本会进一步下降,但降低可读性的成本不会。

简而言之,做可读的事情,它在任何其他意义上都没有任何有用的区别。

【讨论】:

  • 这个过程是免费的吗?
  • @EJP 是的。实际上,内部表示将是一棵树,并且不会有大括号节点。但是大括号将决定它如何构建树,并且编译器很可能会临时插入缺少的大括号,以便正确构建树。 (然而,更有可能的是,编译器只是有两个不同的规则,所以大括号没有任何影响。)
  • @JamesKanze 所以扫描牙套并减少两个额外的产品是免费的吗?请。
  • @EJP:你已经浪费了更多的时间来指出这一点,而不是你在编译效率上得到的回报。但我会更新答案以使其更清晰。
  • 正如我已经说过的“可以忽略不计”,你的评论毫无意义。
【解决方案4】:

机器代码不包含这样的大括号。编译后就没有{}了。使用最易读的形式。

【讨论】:

    【解决方案5】:

    嗯,它们在运行时当然没有区别。 但是为了代码的维护,你当然应该使用第二种方式。

    我这么说的原因是,假设将来您需要添加更多行到您的if-else以扩展它们。然后,如果您在旧代码中包含第一种方法,那么您必须在添加一些新代码之前添加braces。在第二种情况下您不需要这样做。

    因此,将来向第二种方式添加代码比向第一种方式添加代码要容易得多。

    另外,如果你使用第一种方式,你打算在你的if之后输入错误,比如semi-colon,像这样:-

    if (a > 0);
        System.out.println("Hello");
    

    因此,您可以看到您的Hello 将始终被打印出来。如果您将curly braces 附加到您的if,则可以轻松删除这些错误。

    【讨论】:

    • 投反对票是因为幻想大括号可以零时间编译。
    • @EJP.. 是的,我编辑了那部分。在编译时有一些区别。
    • @SingerOfTheFall.. 好吧,它也可以用 Java 编译。但是在声明之后同时添加;{ 的机会非常少,对吗?
    • @EJP.. 而且我不明白,为什么两个具有相同内容的答案会得到不同的反应。在@pbhd'sansweranswer 中,相同的内容获得了 2 个赞
    【解决方案6】:

    这取决于其余的编码指南。我没有看到任何 删除大括号的问题 if 左大括号总是在一行 通过它自己。如果左大括号位于if 行的末尾, 但是,我发现添加内容时太容易忽略。所以 我会去:

    if ( a > 10 ) {
        a = 0;
    }
    

    不管有多少行,或者:

    if ( a > 10 )
    {
        //  several statements...
    }
    

    与:

    if ( a > 10 )
        a = 0;
    

    当只有一个语句时。然而,重要的是, 所有的代码都是一致的。如果您正在处理现有代码 base 使用了几种不同的样式,我总是在 new 中使用大括号 代码,因为你不能指望代码风格来确保如果他们 在那里,他们会在一个非常显眼的位置。

    【讨论】:

    • 您对编码风格的看法并不是对性能问题的回答,性能问题具体排除可读性范围。
    • @EJP 它们永远是选择一种风格或另一种风格的唯一正当理由。它们很重要。 (绝对没有性能差异。)
    • 自 1976 年以来我一直是编译器作者。请收回。你的答案仍然无关紧要。
    • @EJP 我已经编写了许多编译器,但从未发现有什么不同。在一种情况下,您减少了一条规则;另一方面,不同的规则。根据您查找规则的方式,可能(但极不可能)找到一条规则的成本可能高于寻找另一条规则的成本,但两者之间可能存在差异。
    • 我也从未注意到差异:这就是为什么我非常小心说“有限但可以忽略不计”。您可以反驳的唯一方法是证明大括号是在零时间内编译的。你很清楚他们不是。如果遇到左大括号,则必须推送新状态,解析语句,并在遇到右 } 时弹出状态。您还必须扫描 { 和 }。如果大括号不存在,您只需解析语句。其余的都不会发生。因此,存在有限差异。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-05-20
    • 2020-06-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-06-22
    相关资源
    最近更新 更多