XML Comments Quick Reference#

I'll come out and bluntly admit it: I don't mind writing XML comments in my code. Really. I can get pretty freaky about it too if you let me, and I always try to make sure that every comment is kept in sync with the code it's covering. Why? Because if you make the compiler (or a 3rd party tool for those languages that don't support it) emit an XML comments file, it gives you free and up-to-date IntelliSense and even full-blown technical documentation, duh!

So if you're also constantly lost in the MSDN documentation trying to figure out which tags are allowed and what the syntax is, here's a quick reference for your amusement. Now start writing comments, please!

Documentation Sections

  • <summary>

    A short description of the item; describe the members of the type here.

    <summary>text</summary>

  • <remarks>

    The "Remarks" section of the documentation; specify overview information here.

    <remarks>text</remarks>

  • <example>

    The "Example" section of the documentation.

    <example>text</example>

  • <seealso>

    A link in the "See Also" section of the documentation.

    <seealso cref="member">text</seealso>

Member Documentation

  • <param>

    Describes a parameter to a method.

    <param name="name">text</param>

  • <returns>

    The return value of a method.

    <returns>text</returns>

  • <exception>

    The exceptions that can be thrown.

    <exception [cref="type"]>text</exception>

  • <value>

    Describes the value of a property.

    <value>text</value>

  • <permission>

    The permission applied to a member.

    <permission [cref="type"]>text</permission>

Text Formatting

  • <c>

    Format characters as code within other text.

    <c>code</c>

  • <code>

    Multiline section of code.

    <code>code</code>

  • <see cref>

    A link to a type, member or field in the current compilation environment.

    <see cref="member">text</see>

  • <see langword>

    Undocumented. A link to a keyword in the language of the current compilation environment, e.g. null.

    <see langword="keyword"/>

  • <paramref>

    A reference to a parameter within other text.

    <paramref name="name"/>

  • <list>

    A list of items.

    <list type="[bullet|number|table]">
        <listheader>
            <term>name</term>
            <description>text</description>
        </listheader>
        <item>
            <term>name</term>
            <description>text</description>
        </item>
    </list>

  • <para>

    A paragraph within other text.

    <para>text</para>

  • <include>

    Refer to comments in another file.

    <include file='filename' path='tagpath[@name="id"]' />
Blog | Programming | .NET | VS.NET
Monday, January 17, 2005 1:16:29 PM (Romance Standard Time, UTC+01:00)
Right on! People should start paying more attention to documenting their code! I'm actually a practitioner of my own invented methodology, document-first development :)
I was also toying with the idea of writing a little program like http://docs.codehaus.org/display/ASH/Guantanamo, but one that would delete all code that isn't documented. Maintenance would love it!

Seriously now, in reality I don't think documenting every method and parameter is useful, even more, you should try to write code that doesn't need documentation, and choose some intelligent names for your methods, variables etc. But generally, documenting needs to be encouraged more (even if one has to write xml for it).
Monday, January 17, 2005 2:22:54 PM (Romance Standard Time, UTC+01:00)
I couldn't agree more ;-) But I have to say that the xml snippets are quite verbose. I like the way JavaDoc delivers full documentation without the need to browse through lines of xml. But that's just my preference... If you really want xml output from java documentation, you could write an XML aware Doclet. I did a quick google search, but I couldn't find a nice XML Doclet (most projects are cancelled or not maintained anymore).

By the way, I've noticed that the font size of this page changes, is that normal? The font is smaller than the front page.
Monday, January 17, 2005 3:29:30 PM (Romance Standard Time, UTC+01:00)
Nico-

I think "code that doesn't need documentation" is a little naïve. What may seem perfectly clear to you at a certain point in time with the domain-specific knowledge you have at that time, will be much more fuzzy after a while or to somebody else. "Intelligent names" would certainly help but should not be the only kind of documentation. And if you look at naming guidelines, you can see how hard it is just to try and enforce those, let alone that you can enforce "intelligence" of any kind :-)

And I'd be a very strong advocate of your Guantanamo-clone, when can I have it :-)
Monday, January 17, 2005 3:34:23 PM (Romance Standard Time, UTC+01:00)
doggi-

I actually like the VS.NET XML syntax more than the JavaDoc way, since it's very structured and more open to standardized tooling this way.

Also, there's an important difference between the fact that you type the comments in XML-format in the editor (which is really just a matter of flavor and could well be something more like JavaDoc syntax) and the fact that an XML file rolls out of it (which is crucial). The output is what matters most since that's standardized and that's what gets you the actual goodies like IntelliSense and NDoc integration.

(The font size on this page is a little CSS bug indeed, I'll fix that.)
Monday, January 17, 2005 5:49:26 PM (Romance Standard Time, UTC+01:00)
I totally agree with Jelle -- XML comments in combination with NDoc and IntelliSense is just awesome. I use it on all my C# methods, not just the public ones, because you never know who'll have to maintain that code later. And luckily, VB.NET 2005 also has support for XML documentation.

I think XML documentation should be mandatory in every project. For projects where I'm the Big Bad Technical Lead, I don't let developers go home on Friday until all their code is commented properly...
Tuesday, January 18, 2005 9:10:00 AM (Romance Standard Time, UTC+01:00)
Jelle-

IntelliSense and NDoc, please give me a break... Javadoc is NDoc (or the other way around), but it exists already since Java started. You can customize it as much as you want, so I don't see the need for XML-ish docs. IntelliSense is provided in each major Java IDE, so that's no argument.

If I remember correctly, VB.NET doesn't support XML docs yet? So what's standard then? Luckily they will provide it in VS 2005.

Like I said, output of Javadoc is determined by a Doclet. So you can have any output you would ever want, including XML. Don't get me wrong, but I don't believe that XML docs in Visual Studio are that special. The most important thing is of course the documenting part itself. All the rest is merely a geeky discussion ;-)
Tuesday, January 18, 2005 9:31:26 AM (Romance Standard Time, UTC+01:00)
doggi-

Chill dude :-) I think you're misunderstanding me; I'm not comparing anything to Java here, I never said the XML way of Visual Studio .NET is innovating or that they invented it. I'm sure the whole concept is even older than Java (as are most Good Things). As I said, the format in which you type it in the editor is entirely irrelevant (be it angle brackets or @'s) and I just have a minor personal preference towards the XML way. For all I care, VB.NET 2005 can do it with indentation columns the COBOL way :-)

My point is: if you *do* type these structured comments, then you get IntelliSense and NDoc *for free*. The standardized way for .NET is there: that's the xml file rolling out of the compiler. And that's the crucial part I'm talking about because that enables the tooling I mentioned a few times already.

I'm not saying Java doesn't have IntelliSense, I'm not saying XML docs in Visual Studio are special. I'm just saying, use them already, please! They will not only make your life richer and improve your love life drastically, but more importantly it will help the person who comes after you.

Because let's be honest, nobody wants to maintain their own code ;-)
Tuesday, January 18, 2005 9:36:38 AM (Romance Standard Time, UTC+01:00)
Jelle,
I said you should *try* to write code that doesn't need documentation. Plus I make a distinction in documenting 'code' and 'business rules'. I think when you start documenting 'code' your code is too complex, and it would benefit of rethinking about it, maybe another day, with a fresh mind. Of course, the language in which you program is relevant in understanding code without documentation. I can imagine a program in assembler needs more documentation for the 'code' as the same program in Java or C#. As for the domain specific knowledge, eg the business rules, you are totally right, they can and will become fuzzy and should be documented.

Doggi,
I agree with you, I don't see the need for full xml documentation, especially for the text formatting, why hussle with &ltpara&gt when you can write &ltp&gt? Plus html/xhtml is an already existing language people (should) know. Thus eliminating the need for other people to give summaries in their blog about xml comments in .NET :)

PS: blogging about xml and then disallowing &lt and &gt in your comments is asking for trouble :)
Tuesday, January 18, 2005 10:13:07 AM (Romance Standard Time, UTC+01:00)
Nico-

Of course I'm all in favor of method names that tell you what they do (although a DoStuff23() or doStuff23() method can be fun at times), what's up with the bashing here ;-) About documenting code I agree to a certain degree that good code shouldn't require too much comments. Although even if you refactor your code, it could well still be quite complex :-)

The main things that should *always* be well documented are public entrypoints into an assembly/package and definitely reusable components/services (what you might call "business rules documentation"). These define the working constraints of your code as seen from the outside. How your code works internally (what you could call "code documentation") is not the consumer's business and should only interest people who open up the code for editing.

Regarding the "para" comment tag in stead of the "p" we're all used to, I agree: it's a dumb choice and I don't understand the motivation to it either. But you can't "just use html/xhtml" since that doesn't have the proper meta information you need here. The compiler needs to know which tag represents a method summary and which describes the parameters etc. so this is an xml language (schema) in itself and there definitely is a need to document the available tags, and thus to blog summaries of those :-)

On your final point: the comments box says you can't use html so you shouldn't try :-p I know, it's too bad but I can live with it. Rather this than script attacks, right?
Tuesday, January 18, 2005 10:56:52 AM (Romance Standard Time, UTC+01:00)
Public entrypoints need to be documented -> I SO, SO agree, at my previous project we had to use a sparsly documented webservice, which drove me mad!

P and Para, the need for xml schema -> that's why I said especially for text formatting. You are right about the other tags needing to carry extra information.

No html in your comments -> I understand the problem

This marks the end of my bashing (what is a blog without bashing?), now carry on documenting your code :)
Tuesday, January 18, 2005 11:23:22 AM (Romance Standard Time, UTC+01:00)
I still have to make one little remark ;-)

If you have IntelliSense on XML comments, then IntelliSense could figure out which tags can be used in which context. It can even provide a little descriptive comment on how to use it. I don't see the "value" of the summary that you gave above, because why should I have to look through the MSDN in the first place?

;-)
Tuesday, January 18, 2005 11:29:18 AM (Romance Standard Time, UTC+01:00)
doggi-

You're very, very right: there should be IntelliSense on the XML comments. Unfortunately there isn't any and I can't recall if VS.NET 2005 does that but that would be ideal anyway.

In the mean time, the value of my summary above is pretty obvious - to me at least :-) So I'd bookmark this page ;-)
Tuesday, January 18, 2005 9:30:05 PM (Romance Standard Time, UTC+01:00)
Adding a little to the "code should/should not be documented" discussion :-)

You're not just documenting code for yourself, but also for others who will use your code. Say you publish an API, be it on the Internet or "just" inside your company (code reuse, yeah!) Do you want the people using your API to rely on reading your code to figure it all out, or do you want to provide ready information to them in Compiled Help files?

I prefer the latter :-) So hooray for documenting code with inline XML and using NDoc to generate Compiled Help files, MSDN-style, with them!
Monday, May 14, 2007 8:30:20 PM (Romance Standard Time, UTC+01:00)
As usual Vb.NET programmers are the forgotten brother of the Visual Studio team. We have to wait to VS2005 to be able to do XML comments on code ... now we just have to wait until MS team finds time to include a fix to make the unvaluable tag cref to work, they haven't found it to include the fix on SP1 ...

We feel that code documentation is not an option, its a must. A software project is not ended until the documentation is done. Having it joined with the code helps a lot to keep the documentation up to date so its a great thing.

Comments are closed.
All content © 2008, Jelle Druyts
On this page

Recent Photos
www.flickr.com
This is a Flickr badge showing public photos from Jelle Druyts. Make your own badge here.
Advertising
Top Picks
Statistics
Total Posts: 344
This Year: 7
This Month: 0
This Week: 0
Comments: 522
Archives
Sitemap
Disclaimer
This is my personal website, not my boss', not my mother's, and certainly not the pope's. My personal opinions may be irrelevant, inaccurate, boring or even plain wrong, I'm sorry if that makes you feel uncomfortable. But then again, you don't have to read them, I just hope you'll find something interesting here now and then. I'll certainly do my best. But if you don't like it, go read the pope's blog. I'm sure it's fascinating.

Powered by:
newtelligence dasBlog 2.0.7226.0

Sign In