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 storenull 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 thestring 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 = "a";
str += "h";
str += "s";
str += "a";
str += "n";
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}", "a", "h", "s", "a", "n");
If you want to use StringBuilder, here is the code for you: StringBuilder sb = new StringBuilder();
sb.Append("a");
sb.Append("h");
sb.Append("s");
sb.Append("a");
sb.Append("n");
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 theenum 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
Theforeach 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 thetry/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 genericException
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
UseIDisposable 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. 
