JavaDoc
以前实习的时候,组里的代码很少有注释,理解起来着实难受。mentor 可能会说:”不懂的问我,随便问”,但人家只是客气,你要是真随便问就输了。
因此,我写代码尽量带有完整的
JavaDoc注释。如果不做二次开发,个人觉得其实没必要理解一部分代码的实现逻辑。通过完整的 JavaDoc 了解每个方法在做什么,结合调用链路梳理逻辑,就差不多理解业务了。
有人可能会说:良好的代码本身就是一种注释。可是大部分人的代码命名水平实在不怎么高(包括我),变量名中混入拼音首字母缩写的大有人在,有一种 yyds 的美。
而且不是每个人的代码都优雅、简洁的能让大一新生看懂。如果做不到,还是好好写注释吧。
但是话又说回来,如果你的目的是防御性编程,增强自己不可替代的地位,那确实没必要写 JavaDoc。
类名 JavaDoc
1 | /** |
@author作者是谁@since从项目的哪个版本引入的@version该类迭代了几个版本@see与该类相关联的类、方法、或者 URL@deprecated该类若准备删除,可以用这个标签表示。但是要给出删除之后的替代方案。
但其实这只对完美的、非常规范的开发流程生效,一般而言,用 @author 标签记录负责人就足够了。
方法名 JavaDoc
1 | /** |
@param表示方法参数的含义@return返回值的含义@since从项目的哪个版本开始引入@see标记与该方法相关的类、方法、URL 等@throws如果该方法有抛出异常的可能,用该标签标记异常类型(引申:什么时候抛出异常,什么时候捕获异常?)
方法返回类型一眼就可以看到, 真的需要return 标签吗?
假设你对这个方法一点也不了解,当然也不了解这个方法返回值的具体含义,如果有个 return 标签解释了返回值的具体含义,这不是一件很好的事吗?
成员变量 JavaDoc
通常对于成员变量而言,只需使用无标签的文本描述即可
1 | /** |
但为了便于后来者理解,用 @see 标签关联相关信息也可以:
1 | /** |
如何在 JavaDoc 中引用方法、类、成员变量、URL?
看代码:
1 | /** |
上文中所有的 JavaDoc 都遵守着这样的格式:
1 | /** |
但其实除了第一行和最后一行的 *外,其他行开头的 *并不是必须的。
有人说带上 *格式更整洁?可读性更高?
那是不是觉得多行字符串的这种写法也很整洁,可读性更高呢?
1 | String html = "<html>\n" + |
有下面的整洁吗?
1 | // JDK15开始引入的多行文本表达式 |
完整示例如下:
1 | import java.security.MessageDigest; |
附录:所有 JavaDoc 标签
@author- 描述类或接口的作者。
@version- 指定API版本信息。
@since- 标识从哪个版本开始引入了该特性。
@param- 描述方法参数的信息。
@return- 描述方法返回值的信息。
@throws/@exception- 描述可能抛出的异常。
@deprecated- 表示某个类、方法或字段已被弃用,并提供替代方案。
@see- 提供指向其他元素的链接,如类、方法或其他资源。
{@link}和{@linkplain}- 在文本中创建链接到另一个元素,区别在于字体样式(
{@link}使用代码字体,而{@linkplain}使用普通字体)。
- 在文本中创建链接到另一个元素,区别在于字体样式(
{@docRoot}- 代表生成的文档根目录的相对路径。
{@value}- 显示静态字段的值。
@serial- 用于序列化字段的说明。
@serialField- 用于描述
Serializable类中serialPersistentFields成员变量的具体字段。
- 用于描述
@serialData- 描述由
writeObject或readObject方法写入或读取的数据格式。
- 描述由
@code- 将一段文本标记为代码样式。
@literal- 类似于
@code,但不使用等宽字体显示文本。
- 类似于
@inheritDoc- 继承父类或接口的文档注释。
@hidden- 隐藏特定的成员,使其不出现在生成的文档中。
@review- 标记需要审查的部分。
{@index}- 为特定术语创建索引条目。
@apiNote- 提供关于API使用的额外信息。
@implSpec- 描述实现细节,适用于接口默认方法或抽象类中的具体实现。
@implNote- 提供关于实现的额外信息。
@param <T>- 描述泛型类型参数。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 xyhao的博客!









