Question

我正在寻找一个标准的Java注释，它允许我将一些代码标记为“与bug PROJECT-312相关”。目标是能够创建一个报告，我可以看到代码的哪些部分被错误更改或影响。例如，这将允许看到许多错误累积的“热点”。或者它可以很容易地从IDE转到JIRA / BugZilla，看看这个bug到底是什么。

我是否可以/应该使用标准注释，还是必须自己编写？

PS：我知道Mylyn / Tasktop会对我进行跟踪。就我的目的而言，这些工具现在太具有破坏性，因为它们大大改变了人们每天的工作方式。

Answer 1

Oracle方法

Java API规范应该包含足够的断言   使软件质量保证能够编写完整的Java兼容性   Kit（JCK）测试。

这意味着文档注释必须满足需求   SQA的一致性测试。评论不应该记录错误或   目前超出规范的实现如何发挥作用。

来自official JavaDoc guidelines：

代码错误是实现中的错误，而不是API中的错误规格。代码错误及其解决方法通常也是如此在错误报告中单独分发。但是，如果使用Javadoc工具用于生成特定文档实现，包含此信息将非常有用在文档注释中，适当地分隔为注释或自定义标记（比如@bug）。

所以基本上它告诉你不要将文档与错误报告混合在一起。在注释中使用和解析特殊的自定义标记，您不需要比成功的错误报告更多。

此外，使用Eclipse Jira Connect或类似工具，您可以自动将@bug和TODO条评论转换为错误/任务标记。

<强>更新

如果必须，您可以使用几个自定义注释。根据您的需求量身定制，记录并执行整个团队。更多信息here。

@Target({ ElementType.TYPE })
@Retention(RetentionPolicy.CLASS)
// Unavailable through reflection.
public @interface classbug {}
// gives you the @classbug annotation.

@Target({ ElementType.METHOD })
@Retention(RetentionPolicy.CLASS)// Unavailable through reflection.
public @interface methodbug {}
// gives you the @methodbug annotation.

Answer 2

我个人并不认为注释是跟踪热点的正确方法。首先，它们会在有很多错误的区域变得丑陋（比实际代码更多@Bug行！）而另一方面，它们将无益地填充不太可能退化的地方，例如Off-By - 首次实现某些代码时出现错误。

更重要的是，@Bug注释仅在使用时才有用，并且一致使用。执行此操作对所有相关人员来说都是一件麻烦事，并且会在没有提供太多洞察力的情况下减慢人们的速度，因为您无法知道哪些代码受到了错误的影响且没有获得注释。< / p>

更好的是，我会说，将实现一些外部分析，查看受错误修复修订影响的文件（提交消息包含[bB][uU][gG]:? *\d+或类似的东西）并以这种方式运行分析。您可以快速检查所有错误修复，而无需为开发人员添加任何额外的过程。

Google为此提供了一篇有趣的论文：Bug Prediction at Google

对于关于注释比评论更“粘性”的评论，他们有更好的生存机会，我同样想知道这种差异在实践中多么频繁有价值。我经常发现代码中的错误评论不再具有信息性，并且比实际应用的时间更长。如果svn|hg|git|whatever blame相关的行没有显示与相关错误相关的提交，那么从那时起它可能已经多次迭代，但评论仍然存在。

我当然不是说你所描述的从未发生过，但我想知道这种情况经常发生的情况。如果您的经验中的评论在可能仍然有用的情况下消失，请务必查看注释是否会更好。

是否有针对错误的Java注释？

2 个答案: