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.
(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.
public static int Addvalues(int firstVal, int secondVal)
{
}
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)
{
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;
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 namespace
s 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 Namespace
s, 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())
{
}
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.
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");
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
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.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.