Skip to main content
added 223 characters in body
Source Link
Doc Brown
  • 217.6k
  • 34
  • 402
  • 612

Actually I suggest writing a the documentation of a class or function immediately before starting to implement it to get yourself a clear vision of what the requirements and responsibilities of that function or class are. Proof-read the docs after you have a version of your function or class ready, and proof-read it again when you change something. Make the docs complete at every code-review (you do code reviews, don't you?).

And think also about "do I really need that comment, or can I make the function or class names, parameter names etc more self- describing?" Eliminating unnecessary docs is IMHO the most important key for keeping docs and code in sync.

Actually I suggest writing a the documentation of a class or function immediately before starting to implement it. Proof-read the docs after you have a version of your function or class ready, and proof-read it again when you change something.

Actually I suggest writing a the documentation of a class or function immediately before starting to implement it to get yourself a clear vision of what the requirements and responsibilities of that function or class are. Proof-read the docs after you have a version of your function or class ready, and proof-read it again when you change something. Make the docs complete at every code-review (you do code reviews, don't you?).

And think also about "do I really need that comment, or can I make the function or class names, parameter names etc more self- describing?" Eliminating unnecessary docs is IMHO the most important key for keeping docs and code in sync.

Source Link
Doc Brown
  • 217.6k
  • 34
  • 402
  • 612

Actually I suggest writing a the documentation of a class or function immediately before starting to implement it. Proof-read the docs after you have a version of your function or class ready, and proof-read it again when you change something.