Wednesday, August 04, 2010

XML Comments Phase 2

Now as you will be seeing in this XML Tutorial there is no need to create XML file but rather can be inlined with the codes to make well looking and easy to understand code for the users of your library or software. Lets begin with the XML Tutorial for XML Document

The <list> Tag

Some documentation requires lists of various descriptions, and with the <list> tag you can generate numbered and unnumbered lists along with two-column tables. All three take two parameters for each entry in the list — a term and a description — represented by individual XML tags, but they instruct the processor to generate the documentation in different ways.
To create a list in the documentation, use the following syntax, where type can be one of the following values — bullet, numbered, or table: 
   1: <list type="type">
   2: <listheader>
   3: <term>termName</term>
   4: <description>description</description>
   5: </listheader>
   6: <item>
   7: <term>myTerm</term>
   8: <description>myDescription</description>
   9: </item>
  10: </list>

The <listheader> block is optional, and is usually used for table-formatted lists or definition lists. For definition lists, the <term> tag must be included, but for bullet lists, numbered lists, or tables the <term> tag can be omitted.
The XML for each type of list can be formatted differently using an XML style sheet. An example of how to use the <list> tag appears in the following code. Note how the sample has omitted the listheader tag, because it was unnecessary for the bullet list:



   1: /// <summary>
   2: /// This function changes a users password. The password change could fail for
   3: /// several reasons:
   4: /// <list type="bullet">
   5: /// <item>
   6: /// <term>Too Short</term>
   7: /// <description>The new password was not long enough.</description>
   8: /// </item>
   9: /// <item>
  10: /// <term>Not Complex</term>
  11: /// <description>The new password did not meet the complexity requirements. It
  12: /// must contain at least one of the following characters: lowercase, uppercase,
  13: /// and number.
  14: /// </description>
  15: /// </item>
  16: /// </list>
  17: /// </summary>
  18: public bool ChangePwd(string oldPwd, string newPwd)
  19: {
  20: //...code...
  21: return true;
  22: }
The <para> Tag

Without using the various internal block-level XML comments in the XML Document such as <list> and <code>, the text you add to the main <summary>, <remarks>, and <returns> sections all just runs together. To break it up into readable chunks, you can use the <para> tag, which simply indicates that the text enclosed should be treated as a discrete paragraph. The syntax is simple:

<para>This text will appear in a separate paragraph.</para>

The <param> Tag

To explain the purpose of any parameters in a function declaration, you can use the <param> tag. This tag will be processed by the Visual Studio XML comment processor with each instance requiring a name attribute that has a value equal to the name of one of the properties. Enclosed between the opening and closing <param> tag is the description of the parameter:




<param name="parameterName">Definition of parameter.</param>


The XML processor will not allow you to create multiple <param> tags for the one parameter, or tags for parameters that don’t exist, producing warnings that are added to the Error List in Visual Studio if you try. The following example shows how the <param> tag is used to describe two parameters of a function:





   1: /// <param name="oldPwd">Old password-must match the current password</param>
   2: /// <param name="newPwd">New password-must meet the complexity requirements</param>
   3: public bool ChangePwd(string oldPwd, string newPwd)
   4: {
   5: //...code...
   6: return true;
   7: }
The < paramref > Tag



If you are referring to the parameters of the method definition elsewhere in the documentation other than the < param > tag, you can use the < paramref > tag to format the value, or even link to the parameter information depending on how you code the XML transformation. The compiler does not require that the name of the parameter exist, but you must specify the text to be used in the name attribute, as the following syntax shows:

< paramref name="parameterName" / >

Normally, < paramref > tags are used when you are referring to parameters in the larger sections of documentation such as the < summary > or < remarks > tags, as the following example demonstrates:



   1: /// < summary >
   2: /// This function changes a users password. This will throw an exception if
   3: /// < paramref name="oldPwd" / > or < paramref name="newPwd" / > are nothing.
   4: /// < /summary >
   5: /// < param name="oldPwd" > Old password-must match the current password < /param >
   6: /// < param name="newPwd" > New password-must meet the complexity requirements < /param >
   7: public bool ChangePwd(string oldPwd, string newPwd)
   8: {
   9: //...code...
  10: return true;
  11: }
The <permission> Tag

To describe the code access security permission set required by a particular method, use the <permission> tag. This tag requires a cref attribute to refer to a specific permission type:


<permission cref="permissionName">
description goes here
</permission>

If the function requires more than one permission, use multiple <permission> blocks, as shown in the following example:



   1: /// <permission cref="System.Security.Permissions.RegistryPermission">
   2: /// Needs full access to the Windows Registry.
   3: /// </permission>
   4: /// <permission cref="System.Security.Permissions.FileIOPermission">
   5: /// Needs full access to the .config file containing application information.
   6: /// </permission>
   7: public string UserId { get; set; }
The <remarks> Tag

The <remarks> tag is used to add an additional comment block to the documentation associated with a particular method. Discussion on previous tags has shown the <remarks> tag in action, but the syntax is as follows:

<remarks>
Any further remarks go here
</remarks>

Normally, you would create a summary section, briefly outline the method or type, and then include the detailed information inside the <remarks> tag, with the expected outcomes of accessing the member.

The < returns > Tag

When a method returns a value to the calling code, you can use the < returns > tag to describe what it could be. The syntax of < returns > is like most of the other block - level tags, consisting of an opening and closing tag with any information detailing the return value enclosed within:

< returns >
Description of the return value.
< /returns >

A simple implementation of < returns > might appear like the following code:



   1: /// < summary >
   2: /// This function changes a user’s password.
   3: /// < /summary >
   4: /// < returns >
   5: /// This function returns:
   6: /// < c > True < /c > which indicates that the password was changed successfully,
   7: /// or < c > False < /c > which indicates that the password change failed.
   8: /// < /returns >
   9: public bool ChangePwd(string oldPwd, string newPwd)
  10: {
  11: //...code...
  12: return true;
  13: }
The < see > Tag

You can add references to other items in the project using the < see > tag. Like some of the other tags already discussed, the < see > tag requires a cref attribute with a value equal to an existing member, whether it is a property, method, or class defi nition. The < see > tag is used inline with other areas of the documentation such as < summary > or < remarks > . The syntax is as follows:


< see cref="memberName" / >

When Visual Studio processes the < see > tag it produces a fully qualifi ed address that can then be used as the basis for a link in the documentation when transformed via style sheets. For example, referring to an application with a class containing a function named ChangePwd would result in the following cref value:

< see cref="applicationName.className.ChangePwd"/ >

The following example uses the < see > tag to provide a link to another function called CheckUser:



   1: /// < remarks >
   2: /// Use < see cref="CheckUser" / > to verify that the user exists before calling
   3: /// ChangePwd.
   4: /// < /remarks >
   5: public bool ChangePwd(string oldPwd, string newPwd)
   6: {
   7: //...code...
   8: return true;
   9: }
The < seealso > Tag

The < seealso > tag is used to generate a separate section containing information about related topics within the documentation. Rather than being inline like < see > , the < seealso > tags are defined outside the other XML comment blocks, with each instance of <seealso> requiring a cref attribute containing the name of the property, method, or class to which to link. The full syntax appears like so:

<seealso cref="memberName" />

Modifying the previous example, the following code shows how the <seealso> tag can be implemented in code:



   1: /// <remarks>
   2: /// Use <see cref="CheckUser" /> to verify that the user exists before calling
   3: /// ChangePwd.
   4: /// </remarks>
   5: /// <seealso cref="ResetPwd" />
   6: public bool ChangePwd(string oldPwd, string newPwd)
   7: {
   8: //...code...
   9: return true;
  10: }
The <summary> Tag

The <summary> tag is used to provide the brief description that appears at the top of a specific topic in the documentation. As such it is typically placed before all public and protected methods and classes. In addition, the <summary> area is used for Visual Studio’s IntelliSense engine when using your own custom-built code. The syntax to implement <summary> is as follows:

<summary>
A description of the function or property goes here.
</summary>



The <typeparam> Tag

The <typeparam> tag provides information about the type parameters when dealing with a generic type or member definition. The <typeparam> tag expects an attribute of name containing the type parameter being referred to:

<typeparam name="typeName">
Description goes here.
</typeparam>



   1: /// <typeparam name="T">
   2: /// Base item type (must implement IComparable)
   3: /// </typeparam>
   4: public class myList<T> where T : IComparable
   5: {
   6: //...code...
   7: }
The <typeparamref> Tag

If you are referring to a generic type parameter elsewhere in the documentation other than the <typeparam> tag, you can use the <typeparamref> tag to format the value, or even link to the parameter information depending on how you code the XML transformation.





<typeparamref name="parameterName" />


Normally, <typeparamref> tags are used when you are referring to parameters in the larger sections of documentation such as the <summary> or <remarks> tags, as the following code demonstrates:



   1: /// <summary>
   2: /// Creates a new list of arbitrary type <typeparamref name="T"/>
   3: /// </summary>
   4: /// <typeparam name="T">
   5: /// Base item type (must implement IComparable)
   6: /// </typeparam>
   7: public class myList<T> where T : IComparable
   8: {
   9: //...code...
  10: }
The <value> Tag

Normally used to define a property’s purpose, the <value> tag gives you another section in the XML where you can provide information about the associated member. The <value> tag is not used by IntelliSense.

<value>The text to display</value>

When used in conjunction with a property, you would normally use the <summary> tag to describe what the property is for, whereas the <value> tag is used to describe what the property represents:



   1: /// <summary>
   2: /// The <c>UserId</c> property is used in conjunction with other properties
   3: /// to setup a user properly. Remember to set the <c>Password</c> field too.
   4: /// </summary>
   5: /// <value>
   6: /// A string containing the UserId for the current user
   7: /// </value>
   8: public string UserId { get; set; }