tags:

views:

560

answers:

2

I often find myself with a dilemma when writing javadoc for properties/members of a "simple" POJO class holding only properties and getters and setters (DTO-style)....

1) Write javadoc for the property
or...
2) Write javadoc for the getter

If I write javadoc for the property, my IDE (Eclipse) will (naturally) not be able to display this when I later access the POJO via code completion. And there is no standard javadoc tag that lets me link the getter-javadoc to the actual property javadoc.

An example:

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;  
  }  

So, basically it would be interesting to hear how others go about for having your Eclipse IDE display the javadoc property description for your getters - without having to duplicate the javadoc comment.

As of now I'm considering making my practise to only document the getters and not the properties. But it doesn't seem like the best solution...

+3  A: 

You can include private members while generating Javadocs (using -private) and then use @link to link to that fields property.

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

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

Alternatively, if you do not want to generate the Javadoc for all private members, you can have a convention to document all getters and use @link on setters.

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;
    }
}
Chandru
I have experimented with both @link and @see tags.. But... at least Eclipse does not display this properly. Eclipse displays the link as a ...(drumroll) .... link.. that one will have to click in order to see the contents.I want to be able to activate code completion (or by mouse over) get the javadoc for a property when I actually are browsing a getter...
Kenny Brave
A: 

I do both, aided by Eclipse's autocomplete.

First, I document the property:

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

Then, I copy and paste this to the getter:

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

With eclipse, @return statements have an autocomplete - so, I add the word Gets, lowercase the "t", and copy the sentence with the lowercase "t". I then use @return (with Eclipse autocomplete), paste the sentence, and then uppercase the T in the return. It then looks like this:

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

Finally, I copy that documentation to the setter:

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

Then, I modify it and with Eclipse autocomplete you can get not only the @param tag but also the name of the parameter:

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

Then, I'm done. In my opinion, this templating makes it a lot easier, in the long run, to not only remind yourself what the property means through repetition, but also it makes it easier to add additional comments to the getter and setter if you want to add side effects (such as not allowing null properties, turning strings to uppercase, etc). I investigated making an Eclipse plugin for this purpose but I couldn't find the appropriate extension point for the JDT, so I gave up.

Note that the sentence might not always start with a T - it's just the first letter has to be uncapitalized/recapitalized in pasting.

MetroidFan2002
Copy/paste is evil... and time consuming. These steps look like a lot of work, and if the javadoc changes you'll have 3 different places to update.I don't think a plugin would justify this either... atleast, then the plugin would have to e.g. consider the property javadoc to be the master and then overwrite getters (and setters).What I want to accomplish is to write the javadoc in 1 single place, and then have both getters and property javadocs assume the same description...
Kenny Brave
Typically, properties don't change all that often. And the copy and paste operations, with Eclipse's autocomplete, takes less than 30 seconds once the property Javadoc is constructed.
MetroidFan2002
I'm not convinced... Introduction of this type of copy/paste scheme is IMHO bound to lead to inconsistencies.I have too little faith in other cooks (or myself) editing the code later. Also, at least if you're not having a complete up-front design, javadoc properties is often subject to change, at least during a experimental/design phase. And javadoc will be of better quality if written when the code is fresh in mind...Sorry if I seem like a whiner ;-)
Kenny Brave
Sorry, but editing *properties* is bound to lead to inconsistencies - either way you play it, Javadoc tends to fall by the wayside unless it is vigorously maintained in some fashion. Even if there was an easy way to expose the property javadoc, it's just as likely that the property javadoc itself won't be updated. It's really a matter of the coding conventions of the team, etc, and code reviews, stuff like that - good luck to you, this is just the way I do it so I don't forget.
MetroidFan2002
Anyway, thanks for the comments...
Kenny Brave