Coding / Programming Tips for C#

Introduction

This document will discuss the coding style in C# using .NET 2.0 where coding is really reduced, but also includes built-in mechanisms to support most of the extra activities like documenting, indenting the code, etc. to help developer to concentrate on coding rather than on other stuff like setting the environment. Using proper guidelines and a template-framed style of coding will help developers to enjoy coding, produce more understandable, reliable code and streamline application development. Here we will discuss some of the points that help us to improve the coding experience. We will cover the following points which are important for maintaining a uniform coding style.

• Comments
• Identifiers
• Namespace Clashes
• Using #region .. #endregion
• Using try .. catch.. finally
• Using Library functions

Comments

Oh! God not again!

As a developer, I have never been fond of commenting code, but I discovered how important comments are when I started working on a project which was coded by someone else and there was no documentation to help me out! Yes, comments help you lot and that also will help to future developers, too.

In .NET we have different kind of comments which we will review here.

Header Comment

Header comments should be written at the top of files and functions to explain the purpose, author, dates and modification history. This will help understand what is being done in the file, even if there is no source control used.

/* Class file: This file contains the entity for Product,
        with properties and methods about the products.
    Author: 
    Date Created:
    Last Updated: 
    Updated By:
    Update Description:
*/

(Note: This header is not the standard, but you can change the template)

Block Comment/Summary

Block comments (Summary in .NET) should be written at top of functions and should include the information about the purpose, parameters, and return type of the function. This not only gives the information about the function but also shows the same information as a tooltip while writing the call for function.

/// <summary>
/// Methods to add two numeric values
/// </summary> 
/// <param name="firstVal">Int: First Value to add</param> 
/// <param name="secondVal">Int: second Value to add</param>
/// <returns></returns>
public static int Addvalues(int firstVal, int secondVal)
{ 
 // Body of function 
}

After adding the above summary, you can get the information about the function and its parameters while coding as follows:

Single Line Comments

Single line comments should be written to describe special statements or code and the comment lines should be indented to code indentation level.

if (firstval > 0) 
     { 
          // Adding first value to second value if first value is not zero 
          AddValue(firstval, secondval);
     }

Trailing Comments

Trialing comments are generally written on the same line as code with some tabs to separate them. These are short comments generally used to add information about variables, object declarations, etc.

long controlcounts; // Count of the controls in current context 

Identifiers

The following guidelines are referenced by Microsoft for naming identifiers. (See http://msdn.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx)

Pascal case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example: BackColor

Camel Case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. For example: backColor

Uppercase

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example: System.IO or System.Web.UI

The following table summarizes the recommended capitalization rules and provides examples for the different types of identifiers.

Identifier	Case	Example
Class	Pascal	AppDomain
Enum type	Pascal	ErrorLevel
Enum values	Pascal	FatalError
Event	Pascal	ValueChange
Exception class	Pascal	WebException Note: Always ends with the suffix Exception.
Read-only Static field	Pascal	RedValue
Interface	Pascal	IDisposable Note: Always begins with the prefix I.
Method	Pascal	ToString
Namespace	Pascal	System.Drawing
Parameter	Camel	typeName
Property	Pascal	BackColor
Protected instance field	Camel	redValue Note: Rarely used. A property is preferable to using a protected instance field.
Public instance field	Pascal	RedValue Note: Rarely used. A property is preferable to using a public instance field.

Namespace Naming

The general rule for naming namespaces is to use the company name followed by the technology name and optionally the feature and design as follows:
CompanyName.TechnologyName[.Feature][.Design]

For example:Microsoft.Media and Microsoft.Media.Design

Class Naming

The following rules outline the guidelines for naming classes:

• Use a noun or noun phrase to name a class.
• Use Pascal case.
• Use abbreviations sparingly.
• Do not use a type prefix, such as C for class, on a class name. For example, use the class name FileStream rather than CFileStream.
• Do not use the underscore character (_).
• Occasionally, it is necessary to provide a class name that begins with the letter I, even though the class is not an interface. This is appropriate as long as I is the first letter of an entire word that is a part of the class name. For example, the class name IdentityStore is appropriate.
• Where appropriate, use a compound word to name a derived class. The second part of the derived class's name should be the name of the base class. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.

The following are examples of correctly named classes.
[Visual Basic]

Class FileStream
Class Button
Class String

[C#]

class FileStream
class Button
class String

Interface Naming

The following rules outline the naming guidelines for interfaces:

• Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For example, the interface name IComponent uses a descriptive noun. The interface name ICustomAttributeProvider uses a noun phrase. The name IPersistable uses an adjective.
• Use Pascal case.
• Use abbreviations sparingly.
• Prefix interface names with the letter I, to indicate that the type is an interface.
• Use similar names when you define a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the letter I prefix on the interface name.
• Do not use the underscore character (_).

The following are examples of correctly named interfaces.

[Visual Basic]

Interface IServiceProvider
Interface IFormatable

[C#]

interface IServiceProvider
interface IFormatable

Attribute Naming

You should always add the suffix Attribute to custom attribute classes. The following is an example of a correctly named attribute class.

Class ObsoleteAttribute
[C#]
class ObsoleteAttribute{}

Event Naming

The following rules outline the naming guidelines for events:

• Use Pascal case.
• Do not use Hungarian notation.
• Use an EventHandler suffix on event handler names.
• Specify two parameters named sender and e. The sender parameter represents the object that raised the event and is always of type object, even if it is possible to use a more specific type. The state associated with the event is encapsulated in an instance of an event class named e. Use an appropriate and specific event class for the e parameter type.
• Name an event argument class with the EventArgs suffix.
• Consider naming events with a verb. For example, correctly named event names include Clicked, Painting, and DroppedDown.
• Use a gerund (the "ing" form of a verb) to create an event name that expresses the concept of a pre-event, and a past-tense verb to represent a post-event. For example, a Close event that can be canceled should have a Closing event and a Closed event. Do not use the BeforeXxx/AfterXxx naming pattern.
• Do not use a prefix or suffix on the event declaration on the type. For example, use Close instead of OnClose.
• In general, you should provide a protected method called OnXxx on types with events that can be overridden in a derived class. This method should only have the event parameter e, because the sender is always the instance of the type.

The following example illustrates an event handler with an appropriate name and parameters.

[Visual Basic]

Public Delegate Sub MouseEventHandler(sender As Object, e As MouseEventArgs)

[c#]

public delegate void MouseEventHandler(object sender, MouseEventArgs e);

Namespace Clashes

While naming Namespaces, avoid using keywords, and reserved namespace or method names in order to avoid clashes. Following is the example of clashing namespaces

System.Configuration.ConfigurationSettings; MyOrg.Common.Configuration.ConfigurationSettings;

Now if a developer is trying to use a ConfigurationSettings class in an application, even after importing and using both namespaces, a fully qualified names is required to avoid the ambiguity.

Blocking code using #region.. #endregion

While writing long code sections and source files, developers should use #region.. #endregion to separate the code that is related to a group or specific functionality. This help reduce code searching time and make it simpler to understand where things are in the files. An example is shown below:

Exception Handling

In .NET, we can handle exceptions in two different ways. One very general and simple technique is to use try.. catch blocks. The other method is with the using keyword. The using keyword helps developers in two ways:

• A. It actually imports the namespace for the class.
• B. It implements the try..catch block implicitly.
• C. It will call the Dispose() method on all objects implicitly.

For these reasons, if some objects need to be disposed in the calling classes, using keywords are recommended. For example:

using (SqlConnection conn = new SqlConnection()) 
           { 
                //Code here 
           }

Here all the resources in conn will be disposed if there is an exception or when execution completes.

Using try.. catch..finally is really very simple. Enclose resources in a try block, deal with exceptional circumstances in a catch block, and release the resources in the finally block. (See MSDN). Always use try..catch..finally whenever you code for a function or methods.

// try-catch-finally
using System; 

public class EHClass 
{ 
    public static void Main () 
    { 
        try { 
            Console.WriteLine("Executing the try statement."); 
            throw new NullReferenceException(); 
        } 
        catch(NullReferenceException e) 
        { 
            Console.WriteLine("{0} Caught exception #1.", e); 
        }
        catch { 
            Console.WriteLine("Caught exception #2."); 
        }
        finally { 
            Console.WriteLine("Executing finally block."); 
        }
    } 
}

Using Library Functions

In the .NET framework there are numerous pre-defined and well built library function for most needs, but it is necessary to look through the documentation for the libraries to identify the functions that suit our needs. Using pre-built library functions has many advantages as listed below

• A. Helps to reduce the code and bugs since they are pre-built and tested.
• B. These functions are standards, so any developer can understand the functionality.
• C. As most these libraries are pre-compiled, application performance and reliability increases.

It is also recommended that you build your own library to include the business logic in form of re-usable code resources for use in future development and reduce future development costs. The following example illustrates how libraries help us to reduce the code and save our time.

ArrayList arrNames = new ArrayList(); 
arrNames.Add("first"); 
arrNames.Add("second"); 
arrNames.Add("third"); 
arrNames.Add("fourth"); 
arrNames.Add("fifth"); 

// Looping through arraylist to find out the 'third' item 

for (int i = 0; i <= arrNames.Count - 1; i++) 
{ 
    if (arrNames[i].ToString() == "third") 
    { 
        Response.Write("Third item found in array"); 
    } 

}

In this example we can find the ‘third’ item by using library function available for array list as follows

// Using Contains method to find 'third' item in arraylist 
if (arrNames.Contains("third")) 
Response.Write("Third item found in array");

Note that looping and comparing can be avoided by just using the .Contains method.

There are, of course, more things that we as developers can implement to make our code understandable and readable. Without a doubt, having a healthy documentation of process, code, and application is the biggest support for future development and developers.

Happy programming.

Disclaimer: This document is not a standard template and it is not suggested that the recommendations be blindly followed. You can change and interpret the recommendations as needed for your particular circumstances. Note also that part of the information is taken from several other websites like MSDN and I do not claim ownership of those contents. This document is not meant for commercial use.