Commenting for documentation generation

Documenting your source code is always a good idea, whether it is an internal project or external software that will be used by other developers. Internal projects suffer because of developer turnover and often poor, or little to no documentation available to help new developers get up to speed. Many third-party APIs fail to get off the ground or uptake is slower than expected, often with adopters abandoning the APIs through frustration because of the poor state of the developer documentation.

It is always a good idea to include copyright notices at the top of each source code file and to comment on your namespaces, interfaces, classes, enums, structs, methods, and properties. Your copyright comments should be first in the source file, above the using statements and take the form of a multiline comment that starts with /* and ends with */:

/**********************************************************************************
* Copyright 2019 PacktPub
*
* Permission is hereby granted, free of charge, to any person obtaining a copy of
* this software and associated documentation files (the "Software"), to deal in
* the Software without restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the
* Software, and to permit persons to whom the Software is furnished to do so,
* subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in all
* copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*********************************************************************************/

using System;

/// <summary>
/// The CH3.Core.Security namespace contains fundamental types used
/// for the purpose of implementing application security.
/// </summary>
namespace CH3.Core.Security
{
/// <summary>
/// Encrypts and decrypts provided strings based on the selected
/// algorithm.
/// </summary>
public class Cryptography
{
/// <summary>
/// Decrypts a string using the selected algorithm.
/// </summary>
/// <param name="text">The string to be decrypted.</param>
/// <param name="algorithm">
/// The cryptographic algorithm used to decrypt the string.
/// </param>
/// <returns>Decrypted string</returns>
public string DecryptString(string text,
SecurityAlgorithm algorithm)
{
// ...implementation...
throw new NotImplementedException();
}

/// <summary>
/// Encrypts a string using the selected algorithm.
/// </summary>
/// <param name="text">The string to encrypt.</param>
/// <param name="algorithm">
/// The cryptographic algorithm used to encrypt the string.
/// </param>
/// <returns>Encrypted string</returns>
public string EncryptString(string text,
SecurityAlgorithm algorithm)
{
// ...implementation...
throw new NotImplementedException();
}
}
}

The preceding code sample provides an example of a documented namespace and class with documented methods. You will see that the documentation comments for the namespace and contained members start with the documentation comment /// and are directly above the item being commented on. When you type the three forward slashes, Visual Studio automatically generates the XML tags based on the line below.

For example, in the preceding code, the namespace only has a summary and so does the class, but both methods contain a summary, a couple of parameter comments, and a return comment.

The following table contains the different XML tags that you can use in your documentation comments.

From the preceding table, it is clear that you have plenty of scope for documenting your source code. So it is a good idea to make the best use of the available tags to document your code. The better the documentation, the quicker and easier it will be for other developers to get up to speed with using the code.

It is now time to look at cohesion and coupling.