Java切换案例：是否带有花括号？

考虑以下两个带有花括号的代码段：

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

我知道，在带有大括号的代码段中，通过将每个案例放在大括号中创建了一个新的作用域。但是，如果每种情况都不需要新的作用域（即，没有重用变量名），那么将大括号与案例一起使用是否会对性能造成任何影响？

在使用大括号的情况下会有任何性能损失吗？

没有。

花括号可以帮助编译器确定变量，条件，函数声明等的范围。将代码编译成可执行文件后，它不会影响运行时性能。

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

从编译的角度来看，性能会有轻微的损失，因为还有更多要解析的内容，但是如果实际上有人担心它，则必须将所有代码全部写在一行上：-)

现在，对于我们帖子的观点部分，...我总是放在{和}中，因为对可维护性有一个惩罚，因为您可能必须稍后再将它们放入，将它们放入可能会很痛苦稍后...但这是103％的个人偏好。

如我们所知，没有必要为开关盒配备支架。使用花括号案例可能会引起案例范围的混淆。

大括号通常与有意义的东西相关联，例如函数的开始，循环的开始，类的声明的开始或数组初始化的开始等。声明。因此，对于无知的读者来说，使用花括号似乎暗示着大小写范围的不同。因此，最好避免使用花括号以提高程序可读性。

即当我有类似的东西时，

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

  case 2: 
  ....
}

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

就像我们在“ C”中有跳转到标签的语句一样，控件只是转换为大小写并继续执行。因此，基于这种理解，在编写用于切换的案例时使用花括号只是一种糟糕的做法。

从技术上讲，当与有效语法一起使用时，可以用一对大括号将代码的任何块括起来。至少在我看来，在开关中使用括号似乎很糟糕，因为它给人的感觉就像我上面所说的那样。

我的建议：避免在开关盒中使用括号。

带牙套。

switch语句有很多地方可能出错，因此我会尽量避免使用它们，即

1. 忘记休息，因此遇到失败的情况
2. 忘记默认案例，因此不捕获未分类的条件
3. 意外重用案例语句之间的变量，或者更糟的是，影响了在案例语句之间共享变量的变量。

使用花括号是一种防止案例语句之间有意和无意共享变量的方法

这个问题可能会以“议论性”（BRACE WAR！）结束，但是到底是什么。我实际上很喜欢案件之后的牙套。对我来说，它使丑陋的切换语法看起来更像其他语言构造。（在此“案例”中使用花括号没有任何惩罚）

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

花括号实际上最有用的是确保您最终不会case误用相同的变量。他们今天没有声明任何变量，但是明天有人会添加它们，并且没有花括号，代码容易出错。

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

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

• 开关盒应非常短。当您需要声明变量时，这表明您做错了。

现在要维护一些旧的C代码，这些代码可以切换500多个行的情况...

我从来没有想过。从来不需要case子句中的花括号，因此无法真正理解为什么需要它们。就我个人而言，我不赞成“将更易于维护”的想法，这只是垃圾，如果代码有意义并被记录下来，则将更易于维护。

没有大括号...语法越少越好