The Coding Standard

•General Rules

1. Common Sense

1.1 Readability

1.2 Maintainability

1.

2. All code is written in english.

2.1 Strictly forbidding to use double byte space in code.

3. Spacing “ ”

3.1 There should be always spaces around operators (+ / = / == / >)

3.2 Separate logical parts of code by new lines. It makes more for readability than some comments. ( 100 characters per line)

 

•Formatting

1. Braces “{ }”

1.1 Braces should be on new line.

2. Indenting – TAB Character

2.1 Indenting is done with TAB character. No space replacement.

2.2 Indenting should always follow nesting of constructions.

2.3 Configure TAB to 4 space in your VS2005 (or upper).

 

3. Spacing “ ”

3.1 There should be always spaces around operators (+ / = / == / >) .uisng a single space before and after each operator and brackets.

3.2 Separate logical parts of code by new lines. It makes more for readability than some comments. ( 100 characters per line)

3.3 there should be one and only one single blank line bettween each method inside the class. the curly braces should be on a separate line and not in the same line as if ,for etc.

•Naming Conventions

1. Casing

1.1 Use Pascal casing for class names and method names.

1.2 Use Camel casing for variables and method parameters.

2. Abbreviations

1.1 Usage of data type and M_ to represent member variables should be not done.

1.2 Use meaningful, descriptive words to name variables.

• Don’t use abbreviation. Use name, address etc. instead of nam, addr.

• Don’t user single character variable like I, n, x etc. Use names like index and temp.

One exception in this case would be variables used for iterations in loops:

for ( int I = 0; I < count; i++)

{

…

}

 

3. Others

3.1 Don’t use underscores (_) in variable names.

3.2 Namespace names should follow the standard pattern.

<Company Name>.<System Name>.<Top Level Module>.<Bottom Level Module>

•Comments

         1. Do not write comments for every line of code and every variable declared.Write comments wherever required. Good,readable

             code will require very few comments.If all variables and method names are meaningful, that will make the code very readable

             and it will not need much commenting. Fewer line of comments will make the code more elegant. However, if the code is not

             clean/readable and there are fewer comments,that is worrse.If you have to use some complex or weird logic for any reason,

             document it very well with sufficient comments,.If you initialize a numeric variable to a special number other than 0,-1,etc.,

             document the reason for choosing that value. The bottom line is: write clean,readable code in such a way that it doesn't need

             any comments to understand it .Do a spell check on comments and also make sure that proper grammar and punctuation  are used.

         2.  comment should be in same level as the code. curly barces({ }) should be in the same level as code outside be braces. Use one blank line to separate logical groups of code.

 

•Error 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 the case of exceptions ,give a friendly message to the user,but log actual error with all possible details about ther error,including

         the time it occurred, the method and class name etc. Always catch only the specific exception, not generic exceptions .

         Good:

          void ReadFormFile(stirng fileName)

            try

           {

              //read form file

            }

            catch(FileIOException ex)

           {

              //Log Error and show message to user

           }

          finally

            {//dispose resource

            }

 

•Other                        

1. using the C# or VB.Net specific types,rather than the alias types defined in the system namespace .

     Good :int  ,string, long 

     Not Good : Int  ,String,  Long,etc

2. Do not hardcode numbers. Use constants instead.

    Do not hardcode strings.Use resource files.
    Do not use numbers or strings to indicate discrete values.

3. Avoid using many member variables. Declare local varables and pass them to method instead of sharing a member variable between methods.
    If you share a member variable between methods,it will be difficult to track which method changed the value and when. Use enum whevever      requried.

4. Do not make the member variables public or protected. Keep them priavte and expose public/protected properties. Neverr hardcode  a

   path or dirive name in code. Get the application path programmatically  and use relative path. Never assume that your code will run from

   drive C:. You never konw;some user may run it form a network or from a Z:.

   In the application start-up,do some kind of "self check" and ensure that all required files and dependecies are available in the expected location

   Check for database connections at start-up.if required.Give a friendly message to the user in case of any problems.           

   If the required configuration file is not found,the application should ble able to create one with default values. If a wrong value is found in the

   Configuration file.the application should throw an error or give a message and also tell the user what the correct values are.

   When displaying error messages,in addition to telling what is wrong ,the message should also tell what the user should do to solve the probem.

   Instead of a message like "Failed to update the databse" ,sugguest what the user should do:"Failed to update database,Please make sure the

   login ID and password are correct."
   Show shor and friendly messages to user,but log the actual error with all possibale information.This will help a lot in diagnosing problems.