考虑以下两个带括号的片段:
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 回答
我不会在开关盒上使用大括号 .
switch语句看起来很巴洛克,没有大括号 .
开关案例应该很短 . 当你需要声明变量时,这表明你做错了 .
现在关闭维护一些传统的C代码,其中包括500行的运动开关案例......
我以前从未想过这件事 . 从不需要case子句中的大括号,因此无法真正理解为什么需要它们 . 就个人而言,我不会选择“维护更容易”的想法,这只是垃圾,如果代码有意义并且有记录,它将更容易维护 .
没有大括号......语法更少
没有 .
花括号可以帮助编译器找出变量,条件,函数声明等的范围 . 一旦将代码编译成可执行文件,它就不会影响运行时性能 .
这是过早优化的一个极端例子 . 担心哪种方式更容易阅读和调试会更好 .
从执行的角度来看,没有性能损失 .
从编译的角度来看,轻微的性能损失,因为有更多要解析,但如果有人真的关心它,他们将不得不在一行编写他们的代码:-)
现在对于我们帖子的意见部分...我总是加入{和}因为可维护性会受到惩罚,因为你可能不得不把它们放在以后的日期,这可能会让他们痛苦不堪在以后......但这是个人喜好的103% .
我们知道开关盒的支架不是必需的 . 使用大括号案例可能会导致对案例范围的混淆 .
开括号通常与有意义的东西相关联,如函数的开始或循环的开始或类声明的开始或数组初始化的开始等...我们知道,当遇到中断时,一个案例突破了switch块声明 . 因此,使用花括号似乎暗示了对于无知读者的案例的不同范围 . 因此,为了更好的编程可读性,最好避免使用花括号 .
即当我有类似的东西,
“Hello from 1”打印出来 . 但是大括号的使用可能暗示一个无知的读者,案件以'}'结尾,已经知道在循环,方法等情况下花括号通常表示什么 .
就像我们在'C'中有跳转标签语句一样,控制只是转移到大小写并继续执行 . 因此,根据这种理解,在为switch编写案例时使用花括号只是一种不好的做法 .
从技术上讲,当使用有效语法时,您可以使用额外的一对花括号来包围代码的任何块 . 在开关中使用大括号看起来至少对我来说很糟糕,因为它似乎给出了与我上面所说的不同的感觉 .
我的建议:避免使用周围的支架来切换机箱 .
带括号 .
切换语句有很多东西可以出错我尽量避免使用它们,即
忘记休息,从而有案件漏洞
忘记默认情况,从而没有捕获无条件的条件
意外地在case语句之间重用变量,或者更糟糕的是,影响在case语句之间共享变量的变量 .
使用大括号是防止在case语句之间有意和无意地共享变量的一种方法
这个问题可能会被称为“争论性”(BRACE WAR!),但是到底是什么 . 我真的喜欢案件之后的大括号 . 对我而言,丑陋的切换语法看起来更像是其他语言结构 . (在这个“案例”中使用大括号不会受到惩罚)
您说可以省略大括号,因为没有重用变量名称 . 通过重用变量名,我假设你的意思是声明一个相同类型的新变量 .
大括号实际上最有用的是确保您不会错误地在不同的
case
中重复使用相同的变量 . 他们今天没有声明任何变量,但有人会在明天添加它们而没有大括号,代码容易出错 .