On Documentation for (and by) Developers

The government's view of the economy could be summed up in a few short phrases: If it moves, tax it. If it keeps moving, regulate it. And if it stops moving, subsidize it.  - Ronald Reagan

This has become a personal pet - peeve of mine, having been in various developer groups using the .NET platform since 2001 (ancient history, to be sure -- at least by Internet standards).

When I write a class library, if there is even the HINT that it may be used by other developers (or  -- even by me myself at some later date) I've learned to produce decent documentation in the standard XML comment format that has been available in .NET since the very first BETA 1.0 was distributed at the Orlando PDC (Professional Developers Conference) in 2000. 

Here's the "thing": as you progress in your career as a professional .NET developer, you'll learn to produce libraries and classes of useful code that you'll use again and again. The idea is that as you gain more and more experience, the personal resources you have developed to solve common programming tasks will increase, and your job as a programmer should get progressively easier - provided that you have documented your code!  Code I look at that's over six months old - unless it is documented well -- presents a challenge as I try to remember what it does and how it does it. Maybe I'm just having a Senior Moment - but I suspect that this  problem exists for everyone.

The standard XML  format of documentation works well  because there are well established tools (NDoc, Sandcastle, etc.) that can use this metadata to produce professional - quality CHM or HSX Visual Studio / MSDN type help files.

But even more importantly, if you as a developer enable the "XML documentation" path in the Build tab of your project's configuration property sheet, Visual Studio will generate it's standard XML documentation file that normally sits right next to the built assembly in the build output path.

And guess what? When you or anybody else loads this project, that XML documentation file is used  by Visual Studio to provide the developer with - Intellisense! The Intellisense that you - the original developer - authored. You can use, for example, the <remarks>... element to give developers instructional comments that will shorten their learning curve in using your code -- which they probably have never worked with before, no? Looky here:

Putting comments inline inside the body of your methods, or after the end of a line of code, or even inline inside a parameter list with /* comment here */ is useful of course. But standard XML documentation has a specific schema and must be placed just above the class or method declaration in order to be used by the IDE in the manner I've described.

There are several tools that can be used to make this task easier; the best of which (I think) is GhostDoc produced by Roland Weigelt.

In fact I distinctly remember Roland emailing me some time ago asking if it was OK to use some code that I had published for his GhostDoc add-in project -- and of course the answer was that I was delighted.  GhostDoc is indispensible if you strive to be a professional developer and document your code. It automatically produces "best - guess" documentation that you can embellish or improve very easily - and all you need to do is highlight the first (signature)  line of your method, right - click, and choose "Document this". Jeesh -- it doesn't get any easier than this!

Producing quality, standards - based documentation for your work not only establishes you as a professional who cares about others, it can also save a lot of man-hours of work for any developer who is expected to use your creation in their work. Developers often say or think, "I don't have the time to produce documentation". Actually, it's the other way around - if you don't make the time to  produce documentation, you may not have time left for development.

Remember - we don't develop code in a vacuum, even if we are "a team of one". Some months from now, YOU may be the person who is happy that the documentation was provided (by you).

Roland, thanks for providing a great tool!