.NET Framework Naming Conventions and Styles

The bosses are walking across the office as crazy, shouting, shaking papers, nervous...and they are everywhere. And they are asking for Tommy.

Tommy is The Developer, and he has seen this scene before. He knows that another application will be delivered by Friday, and it must be ready for the users on the same day. This is a high priority application.

He works long hours, drink lots of coffee, and fix and release the application as usual. Friday comes:

- Tommy is happy. He is not carrying anymore that heavy burden to deliver the product by Friday.

- The users...well, they are happy. They are just typists anyway, but they are happy.

- The Boss is happy. He finally can show his progress to his boss (yeah...everyone have a boss, even The Boss). 

Congratulations to everybody, nice party, Friday drinks. Tommy goes around like a happy-Larry.

Monday comes and Tommy has to move on. He's been doing this for too long and now he has way too many applications under his umbrella. The company hires a new developer to take care of Tommy's applications.

The next morning someone screams: That's the new hired guy. He almost had a heart attack just looking at Tommy's code...or should I say: His spaghetti.

I think you agree with me, this is not a very hard scenario to imagine, specially if you work in a market where the pressure is always on. I know many people who are great dealing with projects and deadlines, but unfortunately because of "external factors" they must produce something "for yesterday", otherwise the boss won't be happy. And the final result normally is a bunch of applications with almost nothing in common and lacking a very basic thing: Coding Standard.

Microsoft is great when it comes to provide the guidelines for coding practices and stardards (Microsoft Standards, in the case) and you can literally find hundreds of pages about this subject at MSDN.

You can there and read them all by yourself, it is really good reading I am sure of that, but if you are like our friend Tommy and has no time for reading I've gathered the main ones and collected them here for you to save yourself some time:
 

• Use Pascal casing for type and method names and constants

public class MyClass

{
   const int ConstantA= 100;
   public Mymethod( )   {}
}

• Use camel casing for local variable names and method arguments

int internalValue;
void MyMethod(int theParameter){ }

• Prefix interface names with I 

interface IMyInterface {..}

• Private member variables are camelCase
• Custom attribute classes finished with Attribute
• Custom exceptions finishes with Exception
• Methods are named using verb and objects

protected void ShowForm( )

• Functions are named after the returning values description

GetAccountUserName( )

• Alway use clear and well described variable names
• Avoid variable names with just one letter, such as i or t. Call them index, counter or temp instead.
• Do not use Hungarian notation for public or protected members
• Do not abbreviate words
• Always use .NET predefined types, instead of the aliases in the System namespace.

use object instead of Object
use string instead of String

• For generics, capital letters for types. Reserve suffixing Type only when you are referring to the .NET Type 

//Correct:
public class LinkedBankAccountList<InternalKey,Data>{...}

//Wrong:
public class LinkedBankAccountList<KeyType,DataType>{...}

• Give the namespaces a good well-formed name, not some mnemonic
• Avoid fully qualified type names in the code. Use the using statement as much as possible.
• Avoid placing a using statement inside a namespace. (that's a very tricky one)
• Group all framework namespaces together and put custom or third-party namespaces underneath and at the end

using System;
using System.Data;
using MyCompanyDataAccess;
using ExternalCompanyLogicObjects;

• Use delegate inference declared instead of explicit delegate instantiation

delegate void DelegatePrincipal( );
public void MyMethod( ) {...}
DelegatePrincipal thisDelegate = MyMethod;

• Do not use tabs or nonstandard indentation, like one space keystroke. Microsoft recommends three or four spaces
• Comments must be indented at the same level of indentation as the code referred by the comment
• Member variables are declared at the top, with one line separating them from its properties or methods
• Declare a local variable as near as possible to its first use. Release the object, if needed, as soon as you can when its task is finished
• A filename should reflect the class
• When using partial classes, name each file after the logical part that class describes

//MyClass.cs
public partial class MyClass
{...}
//MyClass.DataAccess.cs
public partial class MyClass
{...}

• Place an open curly brace ({) in a new line. Avoid the butterfly indentation.