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 shoshould 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 shoshould be on new line.

2. indenting-Tab character

2.1 indenting is done with Tab character. No space replacement.

2.2 indenting shoshould always follow nesting of constructions.

2.3 configure tab to 4 space in your vs2005 (or upper ).

3. Spacing" "

3.1 There shoshould 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 shoshould be one and only one single blank line bettween each method inside the class. The curly braces shoshould 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 shocould be not done.

1.2 Use meaningful, descriptive words to name variables.

•Don't use abbreviation. UseName, addressEtc. InsteadNam, ADDR.

•Don't user single character variable likeI, n, xEtc. use names likeIndexAndTemp.

One exception in this case wocould 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 shocould 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 shocould be in same level as the code. Curly barces ({}) shocould 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 extends 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

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 user in case of any problems.

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

Configuration file. The application shocould 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 shoshould also tell what the user shocould do to solve the probem.

Instead of a message like "failed to update the Databse", sugguest what the user shoshould do: "failed to update database, please make sure

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.