我们还真的需要@file或@since-JavaDoc标记吗？

在*.java文件中是否使用@since或@file JavaDoc标记？对我来说，这些标签现在已经过时了

@文件： 好处是什么？如果我想找到一个文件，我会使用IDE的“开放资源”功能并键入类名。@file标记只是类名的重复

@自 绝对没有好处。我们有什么版本控制系统？ （这对图书馆来说很有意义，但我特别谈到项目）

---

您认为呢？

JavaDoc中的注释不适合开发库的开发人员。这些信息供使用此库的开发人员使用，他们无法访问您的版本控制系统或源项目。

尤其是@since注释在试图找出方法自库的哪个版本可用时非常有用。
例如，JDKAPI文档中有很多示例。当您试图处理必须同时使用较旧和较新版本的API的代码时非常方便（例如，当我们的工作站安装了1.7 JDK时，我必须创建必须在只有1.6运行时的服务器上运行的代码，因为我们的大多数软件都将在1.7运行时上运行）。

---

哦，并不是每个人都可以访问IDE，在IDE中你可以点击另一个文件。尤其是在服务器上工作时，您通常只能使用命令行和文本编辑器。

就个人而言，我同意“文件”标签，但我仍然使用“自”来表示公司各种项目中使用的自行开发的库。这些文件无法通过版本控制有效跟踪，但我仍然觉得有必要记录作者、内容和更改时间。beeing说，我担心社区更喜欢本节中与问题相关的问题，而较少讨论意见。对我来说，作者标签毫无疑问是绝对有意义的。您应该为库的每个部署版本自动生成JavaDoc。这意味着您和您的库用户能够清楚地跟踪所有内容。无论如何，您应该为库的每个部署版本生成JavaDoc。这意味着您和您的库用户能够清楚地跟踪所有内容。@user6444340对不起，我不明白您会说什么。但是是的，javadoc属于图书馆的每一个版本，我特别提到@since标记。在我看来，它已经过时了，因为如果您想找出第一次出现的方法，您可以跟踪相应javadoc中的每个方法。@user6444340如果您使用API，您不想读取每个javadoc。您想阅读所有的Javadoc来查看在哪个Spring版本中引入了类吗？好的，这是一个参数。我认为这对图书馆来说是有意义的。但对于一个项目，我仍然认为它是绝对过时的。这是没有争议的。干净的解决方案是在本地复制服务器环境。这样Eclipse就会告诉您，您使用的库与您的工作站JDK不兼容。@user6444340您显然从未在该行业工作过，也不知道在现实世界中是如何工作的。仅仅因为你认为在一个完美的世界中，有些东西应该以某种方式起作用并不意味着它会起作用，更不用说现实世界在任何方面都是完美的了。克服你的“比你更神圣”的态度，这种态度在有一点学术理论但没有实践经验的年轻人中是如此普遍。我同意@因为对图书馆来说是有意义的。我在这个行业工作。切换您的工作站JDK版本应该不是什么大魔术吧。如果您不想交付有缺陷的软件，本地复制生产服务器应该是第一件事。我说的是质量。此外，不是每个库都一直使用@since标记。这就是残酷的现实世界；-）