Java交换机案例:有或没有大括号?

时间:2009-03-11 06:00:41

标签: java performance switch-statement

考虑以下两个片段,大括号:

switch (var) {
  case FOO: {
    x = x + 1;
    break;
  }

  case BAR: {
    y = y + 1;
    break;
  }
}

没有大括号:

switch (var) {
  case FOO:
    x = x + 1;
    break;

  case BAR:
    y = y + 1;
    break;
}

我知道,在带有大括号的代码段中,通过将每个案例括在大括号中来创建一个新的范围。但是,如果每个案例都不需要新的范围(即没有重用变量名称),那么在案例中使用括号是否存在任何性能损失?

9 个答案:

答案 0 :(得分:87)

  

对于使用案例的大括号是否存在任何性能损失?

无。

花括号可以帮助编译器找出变量,条件,函数声明等的范围。一旦将代码编译成可执行文件,它就不会影响运行时性能。

答案 1 :(得分:19)

这是过早优化的极端示例。最好还是担心哪种方式更容易阅读和调试。

答案 2 :(得分:19)

从执行的角度来看,没有性能损失。

从编译的角度来看,轻微的性能损失,因为还有更多的解析,但如果有人真正关心它,他们将不得不在一行上编写他们的代码: - )

现在对于我们帖子中的意见部分...我总是加入{和}因为可维护性会受到惩罚,因为你可能不得不把它们放在以后,它可能是一个让他们迟到的痛苦......但这是个人偏好的103%。

答案 3 :(得分:12)

我们知道开关盒的支架不是必需的。使用大括号案例可能会导致对案件范围的混淆。

一个开括号通常与一些有意义的东西相关联,比如函数的开始或循环的开始或类声明的开始或数组初始化的开始等...我们知道,当一个案例突破了switch块时遇到休息声明。因此,使用花括号似乎意味着对于无知读者的案例的不同范围的想法。因此,为了更好地编程可读性,最好避免使用花括号。

即。当我有类似的东西时,

switch(i)
{
  case 1 :
  {
     //do something
  }
  System.out.println("Hello from 1");

  case 2: 
  ....
}

“Hello from 1”被打印出来。但是大括号的使用可能会暗示一个无知的读者,案例以'}'结尾,已经知道在循环,方法等情况下花括号通常表示什么。

就像我们在'C'中有跳转标签语句一样,控制只是转移到大小写并继续执行。因此,根据这种理解,在为switch编写案例时使用花括号只是一种不好的做法。

从技术上讲,当使用有效语法时,您可以使用另外一对花括号来包围代码的任何块。在开关中使用大括号看起来至少对我来说很糟糕,因为它似乎给出了与我上面说过的不同的感觉。

我的建议:避免使用周围的支架来处理开关箱。

答案 4 :(得分:8)

带括号。

切换语句有很多可能出错的地方我尽量避免使用它们,即

  1. 忘记休息,从而让案件陷入困境
  2. 忘记一个默认情况,因此没有捕捉到无条件的条件
  3. 在case语句之间意外地重用变量,或者更糟糕的是,影响在case语句之间共享变量的变量。
  4. 使用大括号是防止在案例陈述之间有意和无意地共享变量的一种方法

答案 5 :(得分:5)

这个问题可能会被关闭为“争论性”(BRACE WAR!),但是到底是什么。我实际上喜欢案件之后的大括号。对我而言,丑陋的切换语法看起来更像是其他语言结构。 (在这种情况下使用大括号不会受到惩罚)

答案 6 :(得分:5)

您说可以省略大括号,因为没有重复使用变量名称。通过重用变量名,我假设你的意思是声明一个相同类型的新变量。

大括号实际上最有用的是确保您不会错误地在不同的case中重复使用相同的变量。他们今天没有声明任何变量,但有人会在明天添加它们而没有大括号,代码容易出错。

答案 7 :(得分:3)

我不会在开关盒中使用大括号。

  • 如果没有大括号,switch语句看起来已经足够巴洛克了。

  • 切换案例应该很短。当你需要声明变量时,这表明你做错了。

现在关闭维护一些传统的C代码,这些代码可以运行500多行的情况......

答案 8 :(得分:1)

我以前从未考虑过这件事。从不需要case子句中的大括号,所以不能真正理解为什么你需要它们。就我个人而言,我不会选择“维护更容易”的想法,这只是垃圾,如果代码有意义并且有记录,它将更容易维护。

没有大括号......语法更少