Some Best Practices for C# Application Development (Explained)

Introduction

Few days ago, in one of my earlier posts, I listed “Some Best Practices for C# Application Development” from my past few years experience, which got a huge hit by my readers. I got a lot of feedback on that too. Many of my readers gave valued suggestions too. In this article, I will discuss most of those points. I will keep this article regularly updated with new best coding practices. Hope I will get more feedback and/or suggestions here too. Let’s start discussing the Best Coding Practices of C# application development. Here are some of them:

Use Proper Naming Conventions

You should prefer proper naming conventions for consistency of your code. It is very easy to maintain the code if consistent naming is used all over the solution. Here are some naming conventions which are generally followed by .NET developers:

• Always use Camel case (A word with the first letter lowercase, and the first letter of each subsequent word-part capitalized) while declaring variables.
   
• Use Pascal (A word with the first letter capitalized, and the first letter of each subsequent word-part capitalized) naming format while declaring Properties.
   
• Avoid all uppercase or lowercase names for properties, variables or method names. Use all uppercase when declaring const variables.
   
• Never use a name that begins with a numeric character.
   
• Always prefer meaningful names for your class, property, method, etc. This will be very useful for you to maintain the code in future. For example, “P” will not give proper meaning for a class. You will find it difficult to know about the class. But if you use “Person”, you will easily understand by it.
   
• Never build a different name varied by capitalization. It is a very bad practice. It will not be useful while developing code, as you will not know what is “person” class and what is “Person” class!!! But from the above scenario, it can be very easily understandable that “person” is an instance variable of “Person” class.
   
• Don't use the same name used in .NET Framework. People who are new to your code have great difficulty to understand it easily.
   
• Avoid adding prefixes or suffixes for your identifiers. Though in some guidelines, they use “m_” and in some other they use “_” as the prefix of variable declaration. I think it is not that much useful. But, it depends on your organizational coding practices. This point is contradictory based on various organizations and there is no strict guidance on it.
   
• Always use “I” as prefix for Interfaces. This is a common practice for declaring interfaces.
   
• Always add “Exception” as suffix for your custom exception class. It will give better visibility to your exception class.
   
• Never prefix or suffix the class name to its property names. It will unnecessarily increase the property name. If “Firstname” is a property of “Person” class, you can easily identify it from that class directly. No need to write “PersonFirstname” or “FirstnameOfPerson”.
   
• Prefix “Is”, “Has” or “Can” for boolean properties like “IsVisible”, “HasChildren”, “CanExecute”. These give proper meaning to the properties.
   
• Don't add prefix for your controls, instead write proper name to identify the control.

Decide between Value Types and Reference Types

Whenever you need to create a type, first ask yourself a question “What you want and Why you want it?”. If you could answer your question, you can decide between the type you want to use. If you want to store your data, use value types and when you want to create an instance of your type by defining the behavior, use reference types. Value types are not Polymorphic whereas, the Reference types can be. Value types are most efficient in terms of memory utilization over reference types and produce less help fragmentation & garbage. If you want to pass values to a method implementation, decide what you want to do and based upon your requirement, decide between value types and reference types. Use of reference type variables actually change the original value but use of value type will create a copy of the original variable and pass across the method. Thus, it protects your original value from accidental changes. Let's see them in real example. In the below code, we are passing the variable “i” as value type and in the method implementation incrementing it by 10. As it was passed by value, you will see the original value “5” as output of the program code.

static void Main(string[] args)
{
	int i = 5;
	SetValues(i);

	System.Console.WriteLine("Currently i = " + i); // will print "Currently i = 5"
}

static void SetValues(int x)
{
	x += 10;
}

In the below code, as we are sending “i” as a reference, it will change the original value of “i” inside the method and hence you will see 15 as the output in the screen.

static void Main(string[] args)
{
	int i = 5;
	SetValues(ref i);

	System.Console.WriteLine("Currently i = " + i); // will print "Currently i = 15"
}

static void SetValues(ref int x)
{
	x += 10;
}

Hence, decide before you start the implementation, else once implemented it will be very difficult to change them over your huge application.

Always Use Properties instead of Public Variables

Reason behind this is, it makes your code properly encapsulated in OOPs environment. By using getters & setters, you can restrict the user directly accessing the member variables. You can restrict setting the values explicitly thus making your data protected from accidental changes. Also, properties give you easier validation for your data. Let's see a small code:

public class Person
{
	public string name;

	public string GetNameInLowerCase()
	{
		return string.IsNullOrWhiteSpace(name) ? 
				string.Empty : name.ToLower();
	}

	public string GetNameInUpperCase()
	{
		return string.IsNullOrWhiteSpace(name) ? 
				string.Empty : name.ToUpper();
	}
}

In the above example, you will see you have to check every time for the Null value as somebody from outside can easily change the value accidentally and create a Bug in your code. If you don't want that Bug in your code, what you will do is, use the property implementation of the variable (making it private) and then access the property. This gives more reliability over your code. Let’s see an example:

public class Person
{
	public string name;

	public string Name
	{
		get
		{
			return string.IsNullOrWhiteSpace(name) ? string.Empty : name;
		}
		set { name = value; }
	}

	public string GetNameInLowerCase()
	{
		return Name.ToLower();
	}

	public string GetNameInUpperCase()
	{
		return Name.ToUpper();
	}
}

Now in this case, you don't have to think about checking the value against Null every time. The getter implementation of the property will take care of it. So, once implementation but use in multiple places. So, if someone explicitly sets the “Name” property to null, your code will have no impact on it. This is just a sample code to discuss with you about the need of property instead of public member variable. Actual implementation may vary based on your requirement.

public class Person
{
	public string Name { get; private set; }
	public string Age { get; }
}

If you don't want anybody to set the Property explicitly from outside, you can just only implement the getter inside the property implementation or mark the setter as private. Also, you can implement the properties from any interface, thus gives you more OOPs environment.

Use Nullable Data Types Whenever Required

Sometimes, you may need to store null as the value of an integer, double or boolean variable. So how can you do this? The normal declaration doesn't allow you to store the null as value. C# now has the feature of nullable data types. Just a small change in your declaration. That’s it!!! You are good to go for storing null values. Only you have to use the “?” modifier. You have to place it just after the type. To define an integer, you would normally do the following declaration:

int index = 0; // simple declaration of int

To convert this as an nullable data type, you have to modify a bit to declare like this:

int? index = null; // nullable data type declaration

Once you add the “?” modifier to the data type, your variable will become nullable and you will be able to store “null” value to it. Generally it is helpful when used with the boolean values.

Prefer Runtime Constants over Compile time Constants

Runtime constants are always preferred than the Compile time constants. Here you may ask what is runtime constant and what is compile time constant. Runtime constants are those which are evaluated at the runtime and declared with the keyword “readonly”. On the other side, compile time constants are static, evaluated at the time of compilation and declared with the keyword “const”.

public readonly string CONFIG_FILE_NAME = "web.config"; // runtime constant
public const string CONFIG_FILE_NAME = "web.config"; // compile time constant

So, what is the need to prefer readonly over const variables? Compile time constants (const) must be initialized at the time of declaration and can’t be changed later. Also, they are limited to only numbers and strings. The IL replaces the const variable with the value of it over the whole code and thus it is a bit faster. Whereas, the Runtime constants (readonly) are initialized in the constructor and can be changed at different initialization time. The IL references the readonly variable and not the original value. So, when you have some critical situation, use const to make the code run faster. When you need a reliable code, always prefer readonly variables.

Prefer “is” and “as” Operators While Casting

It is better to use “is” and “as” operator while casting. Instead of Explicit casting, use the Implicit casting. Let me describe to you with the example of a code.

// this line may throw Exception if it is unable to downcast from Person to Employee
var employee = (Employee) person;

In the above code, suppose your person is a Customer type and when you are converting it to Employee type, it will throw Exception and in that case, you have to handle it using try{} catch{} block. Let’s convert the same using “is” and “as” operators. See the below code:

// check if the person is Employee type
if(person is Employee)
{
	// convert person to Employee type
	employee = person as Employee;
}

// check if the person is Customer type
else if(person is Customer)
{
	// convert person to Customer type
	customer = person as Customer;
}

In the above code, you can see that, in the second line I am checking whether the person is a Employee type. If it is of type Employee, it will go into the block. Else if it is a Customer type, will go to the block at line 12. Now, convert it with the “as” operator, as shown in line 5. Here, if it is unable to convert, it will return as null but will not throw any exception. So, in the next line, you can check whether the converted value is null. Based on that, you can do what you want.

Prefer string.Format() or StringBuilder for String Concatenation

Any operation in the string will create a new object as string is a mutable object. If you want to concatenate multiple strings, it is always better to use string.Format() method or StringBuilder class for the concatenation.

string str = "k";
str += "u";
str += "n";
str += "a";
str += "l";
 
Console.WriteLine(str); 

In case of string.Format(), it will not create multiple objects instead will create a single one. StringBuilder as an immutable object will not create separate memory for each operation. So your application memory management will not be in critical stage. Hence, it is always preferable to do such operations either using string.Format() or StringBuilder.

The above code will create a new string object whenever we add a new string there. Using string.Format(), you can write the following code:

string str = string.Format("{0}{1}{2}{3}{4}", "k", "u", "n", "a", "l");

If you want to use StringBuilder, here is the code for you:

StringBuilder sb = new StringBuilder();
 
sb.Append("k");
sb.Append("u");
sb.Append("n");
sb.Append("a");
sb.Append("l");
 
string str = sb.ToString();

The above two examples will use the same instance of the string every time.

Use Conditional Attributes When You Need Them

Conditional attributes are very helpful when you want to do something only for the debug version. I know something came into your mind, the #if/#endif block. Yes, you can use the #if/#endif blocks to do something specific to the debug version like tracing or printing something to the output screen. Then why shouldn’t we use them? Of course, you can do that. But, there are some pitfalls. Suppose you wrote the following code:

private void PrintFirstName() 
{ 
    string firstName = string.Empty; 
    #if DEBUG 
    firstName = GetFirstName(); 
    #endif 
    Console.WriteLine(firstName); 
}

In this case, it will work perfectly while in debug mode. But, see the other side. When it goes to production, the GetFirstName() will never get called and hence it will print an empty string. That will be a Bug in your code. So, what to do? We can use the Conditional Attribute to overcome this issue. Write your code in a method and set the attribute of type Conditional with DEBUG string. When your application runs in debug mode, it will call the method and in other case, it will not. Let’s see the code here:

[Conditional(“DEBUG”)]
private void PrintFirstName()
{
    string firstName = GetFirstName();
    Console.WriteLine(firstName);
}

The above code actually isolates the function with the Conditional attribute. If your application is running under debug build, it will load the PrintFirstName() into memory on the first call to it. But when it will go to production build (i.e. release build) the method will never get called and hence it will not be loaded into memory. The compiler will handle what to do once it gets the conditional attribute to the method. Hence, it is always advisable to use the conditional attribute instead of the #if pragma blocks.

[Conditional(“DEBUG”)]
[Conditional(“TRACE”)]
private void PrintFirstName()
{
    string firstName = GetFirstName();
    Console.WriteLine(firstName);
}

Also, if you want to set multiple conditional attributes, you can do that by adding multiple attributes as shown above.

Use ‘0’ (zero) as Default Value Enum Value Types

While we write the enum definition, sometime we miss to set the DEFAULT value to it. In that case, it will set automatically as 0 (zero).

public enum PersonType 
{ 
    Customer = 1 
}
 
class Program 
{ 
        static void Main(string[] args) 
        { 
            PersonType personType = new PersonType(); 
            Console.WriteLine(personType); 
    } 
}

For example, the above code will always print 0 (zero) as output and you have to explicitly set the default value for it. But if we change it a bit and add the default value, it will always print the default value instead of 0 (zero).

public enum PersonType 
{ 
    None = 0, 
    Customer = 1 
}
 
class Program 
{ 
        static void Main(string[] args) 
        { 
            PersonType personType = new PersonType(); 
            Console.WriteLine(personType); 
    } 
}

In this case, it will print “None” to the output screen. Actually the system initializes all instances of value type to 0. There is no way to prevent users from creating instance of value type that are all 0 (zero). Hence, it is always advisable to set the default value implicitly to the enum type.

Always Prefer the foreach(…) Loop

The foreach statement is a variation of do, while or for loops. It actually generates the best iteration code for any collection you have. When you are using collections, always prefer to use the foreach loop as the C# compiler generates the best iteration code for your particular collection. Have a look into the following implementation:

foreach(var collectionValue in MyCollection)
{
    // your code
}

Here, if your MyCollection is an Array type, the C# compiler will generate the following code for you:

for(int index = 0; index < MyCollection.Length; index++)
{
    // your code
}

In future, if you change your collection type to ArrayList instead of Array, the foreach loop will still compile and work properly. In this case, it will generate the following code:

for(int index = 0; index < MyCollection.Count; index++)
{
    // your code
}

Just check the for condition. You will see a little difference there. Array has Length property and hence it generated code which calls the Length. But in case of ArrayList, it replaced the Length with Count, as ArrayList has Count which does the same thing. In other scenario, if your collection type implements IEnumerator, it will generate a different code for you. Let’s see the code:

IEnumerator enumerator = MyCollection.GetEnumerator();
 
while(enumerator.MoveNext())
{
    // your code
}

Hence, you don’t have to think which loop to use. The compiler is responsible for that and it will choose the best loop for you. One more advantage of foreach loop is while looping through the Single Dimensional or Multi Dimensional array. In case of Multi Dimensional array, you don’t have to write multi line for statements. Hence, it will reduce the code you have to write. The compiler internally will generate that code. Thus, increases your productivity.

Properly Utilize try/catch/finally Blocks

Yes, properly utilize the try/catch/finally blocks. If you know that the code you wrote may throw some Exception, use the try/catch block for that piece of code to handle the exception. If you know that, the fifth line of your 10 lines code may throw exception, it is advisable to wrap that line of code only with the try/catch block. Unnecessary surrounding lines of code with try/catch will slow down your application. Sometimes, I noticed people surrounding every method with try/catch block which is really very bad and decreases the performance of the code. So from now, use it only when it is required. Use the finally block to clean up any resources after the call. If you are doing any database call, close the connection in that block. The finally block runs whether your code executes properly or not. So, properly utilize it to cleanup the resources.

Catch Only that Exception that You Can Handle

It is also a major one. People always use the generic Exception class to catch any exception which is neither good for your application nor for the system performance. Catch only those which you expect and order it accordingly. Finally at the end, if you want, add the generic Exception to catch any other unknown exceptions. This gives you a proper way to handle the exception. Suppose, your code is throwing NullReferenceException or ArgumentException. If you directly use the Exception class, it will be very difficult to handle in your application. But by catching the exception properly, you can handle the problem easily.

Use IDisposable Interface

Use IDisposable interface to free all the resources from the memory. Once you implement IDisposable interface in your class, you will get a Dispose() method there. Write code there to free the resources. If you implement IDisposable, you can initialize your class like this:

using (PersonDataSource personDataSource = DataSource.GetPerson())
{
    // write your code here
}

After the using() {} block, it will call the Dispose() method automatically to free up the class resources. You will not have to call the Dispose() explicitly for the class.

Split your Logic in Several Small and Simple Methods

If methods are too long, sometimes it is difficult to handle them. It is always better to use a number of small methods based upon their functionality instead of putting them in a single one. If you break them in separate methods and in future you need to call one part, it will be easier to call rather than replicating the code. Also, it is easier to do unit testing for the small chunks rather than a big code. So, whenever you are writing a piece of code, first think of what you want to do. Based upon that, extract your code in small simple methods and call them from wherever you want. In general, a method should never be more than 10-15 lines long.

End Note

Hope these points will help you to understand the C# coding practices properly. There are more points which I didn’t cover here. I will publish them soon in the same thread. If you have any suggestion or comments, please let me know. Cheers…