Thursday, February 07, 2008

C# Coding Standards

I was looking through some oldish code of mine the other day. While most of the code was ok, it was clear I wasn't working to any coding standard at the time.

Some variables are camel cased some Pascal. There were methods where the fields should have been and properties where the methods should have been. It wasn't a disaster, but it was a lot harder than finding stuff in my code these days.

Without wanting to get religious, I thought I would post my coding standard. I'm not arrogant enough to assume everyone will like it, but I think the point of the post is that it is important that some standard is adhered to, and everyone developing on that code knows it, and sticks to it.

I'm not going to go fully into every little feature, just the basics. There a couple of other documents on the net, and of course the "Bible" which I base a lot of my coding standards on.

Code Specifics

1) Private fields should start with the _

Example:

private int _classId;

2) Camel Casing.

All variables and parameters should be camel cased. Abbreviations should be camel cased unless 2 letters or under. Id is a special case and should be camel cased.

Examples:

private Node GetNextChild( Node startNode, Node currentNode)

private int _classId;

private string _memberITDepartmentName;

3) Pascal Casing

All Properties and Methods should be Pascal Cased.

Examples:

public string MemberName
{

get;
set;
}

public int GetMemberId(string memberName)

Code Layout

1) Brace Layout

All braces should be on their own line directly under the code they follow. This includes methods, control and looping statements.

Example:

private void UpdateAll()
{

for (int i = 0; i < 100; i++)
{
...
}
}
 

2) Indentation

All code should be indented where appropriate 4 spaces.

3) Regions

All code should be broken up into regions in this order

Constants, Fields, Constructor(s), Properties, Methods, Delegates, Events

Naming Conventions

1) Variable Naming

Developers are free to name variables as they see fit, but Hungarian notation should not be used, although if agreed upon, HN can be used when naming GUI elements, eg btnOK, btnClose.

Variables should not include the type name of that variable

Example:

private string _connectionString;

2) File Naming

File should be named of the type they are. Class files should start with cls, interfaces should start with I. Interface names should also start with a capital I, but class names should not include the cls.

I'll stop there. I think all the bases are covered, like I said before I think it is important each team has there own standards that are agreed upon and used, but these ones could be a good place to start...

3 comments:

Shaun Austin said...

So come on then, what WOULD you call a connection string? I agree with the "no type names in a name" rule, and enforce it religiously but I've always struggled with the old "connectionString" because basically that's what it is!!!

KiwiBastard said...

connectionStr

Shaun Austin said...

Oh dear, even MORE important is the need to avoid abbreviations. So that matie, is a Fail!!!

Try again!...