Coding Standards

1.    Introduction

Anybody can write code. With a few months of programming experience, you can write 'working applications'. Making it work is easy, but doing it the right way requires more work, than just making it work. Believe it, majority of the programmers write 'working code', but not ‘good code'. Writing 'good code' is an art and you must learn and practice it.

 Everyone may have different definitions for the term ‘good code’. In my definition, the following are the characteristics of good code.

 ·         Reliable

·         Maintainable

·         Efficient

2.    Naming Conventions and Standards

The terms Pascal Casing and Camel Casing are used throughout this document.

Pascal Casing - First character of all words are Upper Case and other characters are lower case.

Example: BackColor

Camel Casing - First character of all words, except the first word are Upper Case and other characters are lower case.

Example: backColor

• Use Pascal casing for Class names

•  Use Pascal casing for Method names

• Use Camel casing for variables and method parameters

• Use the prefix “I” with Camel Casing for interfaces ( Example: IEntity )
• Use Meaningful, descriptive words to name variables. Do not use abbreviations. 
• Do not use single character variable names like i, n, s etc.Use names like index, count, temp  etc. One exception in this case would be variables used for iterations in loops: 

• Prefix boolean variables, properties and methods with “is” or similar prefixes. Ex: private bool _isFinished
• Do not use variable names that resemble keywords.
• Use appropriate prefix for the UI elements so that you can identify them from the rest of the variable

• File name should match with class nameFor example, for the class HelloWorld, the file name should be helloworld.cs (or, helloworld.vb)
• Use Pascal Case for file names

3. Indentation and Spacing

• Use TAB for indentation. Do not use SPACES.  Define the Tab size as 4.
• Comments should be in the same level as the code (use the same level of indentation).

• Curly braces ( {} ) should be in the same level as the code outside the braces.

• Use one blank line to separate logical groups of code

• There should be one and only one single blank line between each method inside the class.
• The curly braces should be on a separate line and not in the same line as if, for etc.

• Use a single space before and after each operator and brackets

• Use #region to group related pieces of code together. If you use proper grouping using #region, the page should like this when all definitions are collapsed

• Keep private member variables, properties and methods in the top of the file and public members in the bottom

4. Good Programming practices

• Avoid writing very long methods. A method should typically have 1~25 lines of code. If a method has more than 25 lines of code, you must consider re factoring into separate methods.
• Method name should tell what it does. Do not use mis-leading names. If the method name is obvious, there is no need of documentation explaining what the method does.

• A method should do only 'one job'. Do not combine more than one job in a single method, even if those jobs are very small.

• Convert strings to lowercase or upper case before comparing. This will ensure the string will match even if the string being compared has a different case.

• Use String.Empty instead of “”

• Use enum wherever required. Do not use numbers or strings to indicate discrete values.

• Do not make the member variables public or protected. Keep them private and expose public/protected Properties.
• The event handler should not contain the code to perform the required action. Rather call another method from the event handler.
• Do not programmatically click a button to execute the same action you have written in the button click event. Rather, call the same method which is called by the button click event handler
• Never hardcode a path or drive name in code. Get the application path programmatically and use relative path.
• In the application start up, do some kind of "self check" and ensure all required files and dependancies are available in the expected locations. Check for database connection in start up, if required. Give a friendly message to the user in case of any problems
• Avoid having very large files. If a single file has more than 1000 lines of code, it is a good candidate for refactoring. Split them logically into two or more classes.

5. Comments

• Do not write comments for every line of code and every variable declared
• Use // or /// for comments. Avoid using /* … */
• Write comments wherever required. But good readable code will require very less comments. If all variables and method names are meaningful, that would make the code very readable and will not need many comments.
• Do not write comments if the code is easily understandable without comment. The drawback of having lot of comments is, if you change the code and forget to change the comment, it will lead to more confusion.
• Fewer lines of comments will make the code more elegant. But if the code is not clean/readable and there are less comments, that is worse
• If you initialize a numeric variable to a special number other than 0, -1 etc, document the reason for choosing that value
• Perform spelling check on comments and also make sure proper grammar and punctuation is used.

6. Exception Handling

• Never do a 'catch exception and do nothing'. If you hide an exception, you will never know if the exception happened or not
• In case of exceptions, give a friendly message to the user, but log the actual error with all possible details about the error, including the time it occurred, method and class name etc
• Always catch only the specific exception, not generic exception

• When you re throw an exception, use the throw statement without specifying the original exception. This way, the original call stack is preserved.

• Do not write very large try-catch blocks. If required, write separate try-catch for each task you perform and enclose only the specific piece of code inside the try-catch. This will help you find which piece of code generated the exception and you can give specific error message to the user.