我使用Eclipse,所以对我来说,使用//$FALL-THROUGH$
注释是关于switch语句等的常见做法。但我的同事使用Netbeans并质疑我在做什么。尝试谷歌任何带有符号的东西就像试图用一对冷冻手套拉动牙齿而没有工具......
是使用//$FALL-THROUGH$
评论,美元符号和所有标准java事物,还是某种Eclipse魔法?如果我在Netbeans或其他IDE中加载相同的代码,或者通过独立的java编译器运行它,那么通过switch语句仍然会被标记为警告,即使是否有所述评论?除了使用@SupressWarning
注释之外,是否有一种标准方法可以做到这一点(考虑到你必须使用它,这会简单地混淆代码)?
答案 0 :(得分:11)
这样的事情依赖于IDE /样式检查工具。没有“标准的Java评论”。
(嗯,Javadocs是标准的,但它们不控制编译/错误报告。)
eclipse release documentation中提到了$FALL-THROUGH$
构造的解释:
现在可以通过在以下case语句前面添加一个以$ FALL-THROUGH $开头的注释来抑制switch case语句中预期的掉落的编译器问题。对于无法使用J2SE-5.0样式的@SuppressWarnings(“fallthrough”)注释的代码,这尤其有趣。
请注意,@Suppresswarnings
注释的警告名称取决于编译器,而不是Java语言标准。
答案 1 :(得分:3)
我见过其他采用类似评论方案的工具(例如FindBugs)。但没有什么是标准化的。
在大多数情况下,只有在case语句包含掉落之前的代码时才会抛出这些警告。在大多数情况下,您可以通过分解公共代码来避免这种情况。
例如,这通常不会触发警告:
switch (foo) {
case 1:
case 2:
doSomething();
break;
...
}
但这会:
switch (foo) {
case 1:
doSomething();
case 2:
doSomethingElse();
break;
...
}
我个人认为警告是有原因的。我认为重构公共代码更具可读性和安全性,并且没有非空的漏洞:
switch (foo) {
case 1:
doSomething();
doSomethingElse();
break;
case 2:
doSomethingElse();
break;
...
}
答案 2 :(得分:2)
此评论是特定于IDE的,可能会因其他ide和代码检查程序而失败,尽管findbugs足够聪明,可以检查带有单词的评论。但是,在任何情况下,你都不应该依赖评论来做更多的事情,而不是直接指导程序员,你只需要创建一个维护的东西。