Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details. What if you need to change the accessed field's type? You also have to change the accessor's return type.
Doc comments for constructors Constructors have @param tags but not @return tags. Everything else is similar to methods.
The getter should start with 'get', followed by the member name, with its first letter capitalized. Also the latest conventions I heard of, say that we should avoid multiple capital letters one after another. For example getHTMLtooltip is wrong. it should be getHtmlTooltip instead.
Absolutely pointless - you're better off without this kind of crap cluttering your code:
/**
* Sets the foo.
*
* @param foo the foo to set
*/
public void setFoo(float foo);
Very useful, if warranted:
/**
* Foo is the adjustment factor used in the Bar-calculation. It has a default
* value depending on the Baz type, but can be adjusted on a per-case base.
*
* @param foo must be greater than 0 and not greater than MAX_FOO.
*/
public void setFoo(float foo);
Especially the explanation of what the property actually means can be crucial in domain models. Whenever I see a bean full of properties with obscure names that only investment bankers, biochemists or quantum physicists understand, and the comments explain that the setGobbledygook() method "sets the gobbledygook.", I want to strangle someone.
I usually just fill the param part for setters, and the @return part for getters:
/**
*
* @param salary salary to set (in cents)
*/
public void setSalary(float salary);
/**
* @return current salary (in cents, may be imaginary for weird employees)
*/
public float getSalary();
That way javadoc checking tools (such as Eclipse's warnings) will come out clean, and there's no duplication.
Generally nothing, if I can help it. Getters and setters ought to be self-explanatory.
I know that sounds like a non-answer, but I try to use my time for commenting things that need explanation.
I'd say only worry about commenting getters and setters if they have some sort of side effect, or require some sort of precondition outside of initialization (i.e.: getting will remove an item from a data structure, or in order to set something you need to have x and y in place first). Otherwise the comments here are pretty redundant.
Edit: In addition, if you do find a lot of side effects are involved in your getter/setter, you might want to change the getter/setter to have a different method name (ie: push and pop for a stack) [Thanks for the comments below]
Ask yourself what do you want people to see when the comments are viewed as JavaDocs (from a browser). Many people say that documentation is not necessary since it's obvious. This won't hold if the field is private (unless you explicitly turn on JavaDocs for private fields).
In your case:
public void setSalary(float s)
public float getSalary()
It's not clear what salary is expressed in. It is cents, dollars, pounds, RMB?
When documenting setters/getters, I like to separate the what from the encoding. Example:
/**
* Returns the height.
* @return height in meters
*/
public double getHeight()
The first line says it returns the height. The return parameter documents that height is in meters.
Why don't they just include a reference tag to let you comment the field value and the reference from getters and setters.
/**
* The adjustment factor for the bar calculation.
* @HasGetter
* @HasSetter
*/
private String foo;
public String getFoo() {
return foo;
}
public void setFoo() {
this foo = foo;
}
So that the documentation applies to the getter and setter as well as the field (if private javadocs is turned on that is).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With