tags:

views:

548

answers:

6

This doesn't have to be Java, but it's what I'm dealing with. Also, not so much concerned with the methods and details of those, I'm wondering about the overall class file.

What are some of the things I really need to have in my comments for a given class file? At my corporation, the only things I really can come up with:

  • Copyright/License
  • A description of what the class does
  • A last modified date?

Is there anything else which should be provided?

One logical thing I've heard is to keep authors out of the header because it's redundant with the information already being provided via source control.

Update: JavaDoc can be assumed here, but I'm really more concerned about the details of what's good to include content-wise, whether it's definitive meta-data that can be mined, or the more loose, WHY etc...

+5  A: 

No to the "last modified date" - that belongs in source control too.

The other two are fine. Basically concentrate on the useful text - what the class does, any caveats around thread safety, expected usage etc.

Implementation comments should usually be about why you're doing something non-obvious - and should therefore be rare. (For instance, it could be because some API behaves in an unusual way, or because there's a useful shortcut you can use but which isn't immediately obvious.)

Jon Skeet
+12  A: 

One logical thing I've heard is to keep authors out of the header because it's redundant with the information already being provided via source control.

also last modified date is redundant

I use a small set of documentation patterns:

  • always documenting about thread-safety
  • always documenting immutability
  • javadoc with examples
  • @Deprecation with WHY and HOW to replace the annotated element
  • keeping comments at minimum
dfa
+1 for more details on some good practices of what to document, and I would give it for the deprecation comment alone. It is unbelievably frustrating when someone deprecates without explanation.
altCognito
you can also use empty annotation like @ThreadSafe, @Immutable, etc in order to improve your documentation
dfa
+1 for @Deprecation!
Aaron Digulla
+2  A: 

For the sanity of yourself and future developers, you really ought to be writing Javadocs.

Pesto
I've assumed this is already the case. Does anyone *not* write Javadocs?
Jon Skeet
I don't write Javadocs, at least not in 95% of the cases. I rename the method and/or split it into smaller parts, so that it will be self-explanatory what the code does.
Esko Luontola
@Jon Skeet: Never assume, you'll make an ass out of you and Windows ME.
Pesto
A: 

An overall description of the purpose of the class, a description for each field and a contract for each method. Javadoc format works well.

tehblanx
+2  A: 

When you feel the need to write comments to explain what some code does, improve the readability of the code, so that comments are not needed. You can do that by renaming methods/fields/classes to have more meaningful names, and by splitting larger methods into smaller methods using the composed method pattern.

If even after all your efforts the code is not self-explanatory, for example the reason why some unobvious code had to be written is not clear from the code, then apologize by writing comments. (Sometimes you can document the reasons by writing a test which will fail, if somebody changes the unobvious-but-correct code to do the obvious-but-wrong thing. But having a comment in addition to that is also useful. I prefix such comments often with "// HACK:" or "// XXX:".)

Esko Luontola
A: 

If you assign ownership of components to particular developers or teams, owners should be recorded in the component source or VCS metadata.

Novelocrat