Javadoc评论与块评论？
什么时候在方法的开头使用块注释是合适的，什么时候使用javadoc风格的注释是合适的？
从Java风格指南的“评论”部分，我发现这一点：
Java程序可以有两种评论：实现评论和文档评论。 实现注释是在C ++中find的，由
/*...*/和//分隔。 文档注释（被称为“doc注释”）是仅限于Java的，并由/**...*/分隔。 可以使用javadoc工具将文档注释提取到HTML文件。实施意见是为了评论代码或对特定实施的评论。 Doc注释旨在从实现自由的angular度描述代码的规范。 由可能不一定具有源代码的开发人员阅读。
所以，另一种解释我的问题的方法是：何时应该从一个实现自由的angular度（Javadoc），而不是一个特定的实现的评论，而不是一个特定的实现的评论，应该得到一个规范的代码，反之亦然？ 会有一个接口获得javadoc评论，而实现获取块评论？
编辑：我想我不是正确地传达我的问题，根据迄今为止的答案。
这是我想知道的一个例子。
/** * Javadoc comment here about general implementation? */ /* * Should I now have a separate block comment for my specific implementation? */ public void foo() { ... }
两种不同的评论风格传达了两种不同types的信息。 有什么情况下，方法应该有一个领先的javadoc评论，并领先的块评论？
甚至问的灵感是Eclipse自动生成这个对我来说刚才：
/* * (non-Javadoc) * @see my.package#process() */
而且我认为这里有一些样式，并没有在我上面链接的评论规范中明确声明。
一个类的用户需要知道的信息应该进入一个Javadoc评论。
开发人员需要知道的信息需要进入正常的评论（块或行）。
当代码块（类，接口，字段，方法，构造函数等）可能同时具有Javadoc注释和普通注释块时，如果需要公共可见的以及内部文档，这是非常可能的。
就我个人而言，我倾向于写非常less的非Javadoc评论，因为我更喜欢以自我logging的方式来构build我的代码。
在我看来，Javadoc评论是你写给使用你的代码的人以及谁调用你的方法的评论。
Javadoc评论更关注方法的参数，你的方法将返回什么取决于你给你的方法的参数。
阻止评论是内部评论，你为维护你的代码的人写的评论。
阻止注释对于理解代码是如何工作的，为什么会起作用，以及哪些是用于执行实际工作的操作而言非常重要。
在我看来，把块评论放在方法的顶部是没有意义的（呃，至less大部分时间都不要说永远不会）。 Javadoc对接口方法的评论指定了合同，他们讲述了关于实现的类方法，所以如果有多个类实现单个接口，用户可以决定使用哪个类。 想想List界面; 实现ArrayList和LinkedList适用于不同的用例，因此它们各自的文档可能会解释它们的优缺点。
我内嵌块意见非常具体的事情。 我希望直接在实现的地方实现特定的文档。 当然，你应该尽可能less地使用它们。 使用富有performance力的variables和方法名称，并自动添加底层文档。
Eclipse的自动生成的块注释是为你填写，并可能通过添加缺less的星号使他们Javadoc评论。 我不清楚它们出现在哪些情况下，但是当你从现有的类中提取一个接口的时候。 然后，类Javadoc进入接口方法，类方法获取块注释。 这背后的原因是，通常当实现一个接口，你真的没有太多的补充。 我再次使用List作为例子。 size()方法在ArrayList和LinkedList实现中不需要更多的文档。 他们没有什么有价值的补充。 当然，这个例子是有意思的，因为实际的实现（至lessOpenJDK） 确实有Javadoc，但我认为没有必要，实际上也没有增加任何有价值的东西。 更糟糕的是，它们提供的信息甚至比接口文档还要less 。
