This is the way Sun suggests in their Javadoc "style
guide". For the @param tag, they write: "The @param tag
is followed by the name (not data type) of the
parameter, followed by a description of the parameter.
By convention, the first noun in the description is the
data type of the parameter."
Earlier, they suggest: "Keywords and names are offset
by <code>...</code> when mentioned in a description.
This includes: Java keywords, package names, class
names, method names, interface names, field names,
argument names, code examples."
Put the two guidelines together and you have:
@param name <code>data type</code>
I admit Sun is not so specific for @return values, and
I do concur that @return parameters may be better
served by providing a description of what's returned,
rather than just the data type. However, I thought that
providing the data type would be good as a default.
Sun also gives as an example for boolean return values:
<code>true</code> if ...; <code>false</code> otherwise.
---
Include adding lots of variables to replace the {0}
style variables available at the moment, which are
rather inconsistent. Probably including:
{user} - user name (as per login)
{altuser} - alternative user name (say for instance a
mailto: address).
{class} - the class name
{class.enc} - the enclosing class name
{method} - the method name
{type} - the parameter (or return) type
{date} - the current date
{?} - the stripped name for a getter/setter
{?} - the stripped name for a getter/setter with
initial letter in lowercase
{?} - the stripped name for a getter/setter split into
words
{?} - is 'class' or 'object' depending on whether the
method is static.
where {?} is where I haven't decided what to call them.
---
produce canned JavaDoc for:
String toString()
boolean equals(Object o)
int hashCode()
Object clone()
---
handle copy constructors.
---
handle Listener methods (i.e addActionListener()),
events and actions, as special JavaDoc.
---
handle
static SomeClass instance().
---
Logged In: YES
user_id=476481
Additional variable for &quot;addXxx&quot; comment
Add name of the parameter broken into words, similar
to get and set.
Logged In: YES
user_id=476481
Comments for add / remove listener methods looks
strange (feature?). Example:
/**
* Adds a feature to the MachineListener attribute of
the Machine object
*
* @param l The feature to be added to the
MachineListener attribute
*/
public synchronized void addMachineListener
(MachineListener l) {
Logged In: YES
user_id=476481
Add removeSomething template