如何编写属性的Javadoc?


93

在为仅包含属性以及getter和setter(DTO风格)的“简单” POJO类的属性/成员编写Javadoc时,经常会遇到两难境地。

1)为属性写Javadoc
或...
2)为getter写Javadoc

如果我为该属性编写javadoc,那么当我稍后通过代码完成访问POJO时,我的IDE(Eclipse)自然将无法显示此内容。而且没有标准的javadoc标记可让我将getter-javadoc链接到实际属性javadoc。

一个例子:

public class SomeDomainClass {

  /**
   * The name of bla bla bla
   */
  private String name;

  /**
   * @return INSERT SOME SMART JAVADOC TAG LINKING TO name's javadoc
   */
  public String getName() {  
    return name;  
  }  

因此,基本上,听到其他人如何使Eclipse IDE显示您的吸气剂的javadoc属性描述会很有趣-无需重复javadoc注释。

到目前为止,我正在考虑使我的实践仅记录吸气剂,而不记录属性。但这似乎不是最好的解决方案...


1
有关此的有趣讨论:stackoverflow.com/questions/1028967/…。接受的答案解决了您对Eclipse / javadoc的询问。
b.roth

好像他们以我正在考虑的结论而结束...仅在getter中编写属性javadoc。

我找到了一种方法来处理在eclipse中可用的注释,甚至可以在运行时收集注释,这是一种选择吗?
水瓶座力量

私有成员需要javadoc吗?
谢里

bla bla bla的名称:最好的例子
Rodrigo Espinoza,

Answers:


75

您可以在生成Javadocs时包含私有成员(使用-private),然后使用@link链接到该fields属性。

public class SomeDomainClass {
    /**
     * The name of bla bla bla
     */
    private String name;

    /**
     * {@link SomeDomainClass#name}
     */
    public String getName() {
        return name;
    }
}

另外,如果您不想为所有私有成员生成Javadoc,则可以使用约定记录所有getter并在setter上使用@link。

public class SomeDomainClass {
    private String name;

    /**
     * The name of bla bla bla
     */
    public String getName() {
        return name;
    }

    /**
     * {@link SomeDomainClass#getName}
     */
    public void setName(String name) {
        this.name = name;
    }
}

2
我已经尝试了@link和@see标记。。但是……至少Eclipse无法正确显示此标记。Eclipse将链接显示为...(鼓)....链接。单击该链接即可查看内容。我希望能够在我实际浏览吸气剂时激活代码完成(或通过鼠标悬停)获取属性的javadoc ...

13
@Kenny-不要从Eclipse的可用性的POV模型化JavaDoc实践。从获得正确(或足够好)的JavaDoc输出的POV中进行操作。IDE发生了变化,今天可能存在的不足可能会在明天得到解决(或者您可能实际上完全更改了IDE。)
luis.espinal 2011年

1
@luis @link意味着必须单击链接才能查看实际的Javadoc。这不是Eclipse可用性问题,而是提供易于使用的javadocs的错误解决方案。
NateS

4

Lombok是用于此类任务的非常方便的库。

@Getter
@Setter
public class Example {
    /**
     * The account identifier (i.e. phone number, user name or email) to be identified for the account you're
     * requesting the name for
     */
    private String name;
}

这就是您所需要的!该@Getter注释会为每个私人领域的getter方法和javadoc的附加到它。

PS:该库具有许多不错的功能,您可能需要检出


3

在Eclipse的自动完成功能的帮助下,我都做到了。

首先,我记录该属性:

/**
 * The {@link String} instance representing something.
 */
private String someString;

然后,我将其复制并粘贴到吸气剂中:

/**
 * The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

使用eclipse时,@ return语句具有自动完成功能-因此,我添加单词Gets,将小写的“ t”添加为小写,然后将句子复制为小写的“ t”。然后,我使用@return(使用Eclipse自动完成功能),粘贴句子,然后在返回中大写T。然后看起来像这样:

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

最后,我将该文档复制到设置器中:

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

然后,我对其进行修改,并使用Eclipse自动完成功能,不仅可以获取@param标记,还可以获取参数的名称:

/**
 * Sets the {@link String} instance representing something.
 * @param someString The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

然后,我完成了。在我看来,从长远来看,这种模板将使它容易得多,不仅可以提醒自己该属性通过重复的含义,而且还可以使您更轻松地向getter和setter添加其他注释。效果(例如不允许null属性,将字符串变为大写等)。我调查了为此目的制作Eclipse插件的过程,但是找不到适合JDT的扩展点,所以我放弃了。

请注意,句子不一定总是以T开头-只是粘贴中的第一个字母不能大写/大写。


23
复制/粘贴是邪恶的……而且很费时间。这些步骤看起来很繁琐,而且如果javadoc更改,您将有3个不同的地方可以更新。我认为插件也不足以证明这一点……至少,然后插件将不得不例如将属性javadoc视为主对象,然后覆盖getter(和setter)。我想要完成的是将Javadoc放在一个位置,然后让getter和属性javadocs都使用相同的描述...

通常,属性不会经常更改。一旦构建了Javadoc属性,借助Eclipse的自动完成功能,复制和粘贴操作将花费不到30秒的时间。
MetroidFan2002 '02

4
我不相信...恕我直言,这种类型的复制/粘贴方案的引入必然导致不一致。我对其他厨师(或我自己)以后编辑代码的信心不足。另外,至少如果您没有完整的前期设计,则至少在试验/设计阶段,javadoc属性通常会发生变化。如果在编写新代码时编写Javadoc,质量会更高……对不起,如果我看起来像是在

1
抱歉,但是编辑属性势必会导致不一致-无论您使用哪种方式,Javadoc都会被抛在一边,除非以某种方式大力维护它。即使有一种简单的方法公开属性javadoc,也很可能不会更新属性javadoc本身。这实际上是团队的编码约定等问题以及代码审查之类的问题-祝您好运,这就是我这样做的方式,所以我不会忘记。
MetroidFan2002 '02

@Metroid- 除非以某种方式进行有力的维护-好吧,如果将其视为源代码本身的一部分,则应该有力地维护它。尽管可悲的是它是标准做法,但并没有将Javadoc注释(及其在其他语言中的等效语言)作为代码的固有部分,却是许多弊端的根源。最糟糕的评论是已经过时的评论。充其量,它们会使程序员无法掌握代码(因为他们必须不断地重新验证并接受/拒绝过时的注释。)更糟糕的是,它们会提供易于出错,引入错误的信息。
luis.espinal,2011年

0

我真的认为这是一个问题,Javadoc官方指南对此没有任何说明。C#可以使用Properties用法以优雅的方式解决此问题(我没有用C#编写代码,但我确实认为这是一个不错的功能)。

但是我有一个猜测:如果您需要解释someString是什么,也许对您的代码来说是一个``坏小事情''。这可能意味着您应该编写SomeClass来键入someString,以便在SomeClass文档中解释什么是someString,而这样就不必使用getter / setter中的javadocs。


1
关于代码中字符串的不正确用法,请在《有效Java》一书中查看``在其他类型更合适的地方避免使用字符串''。
莱昂纳多·莱特2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.