Coding Standards for .NET 3.5

1. One class per file & Filename of Class should be same as Class name. Class name should be in noun, in Pascal case. Suffix 'cl' after class name. (e.g.: class SalesOrdercl ;). Follow doxygen compatible comment convention before every class.

2. Interface names use Pascal case and begin with the letter "I".

3. Indentation is constructed with spaces (2 spaces).

   Note: Set Tab with 2 spaces.

4. When an expression will not fit on a single line, break it after an operator OR a comma OR indent once after a break.

5. Comment should contain information that is relevant to reading and understanding the program. Implementation comments are meant for comments about the particular implementation. Documentation comments are meant to describe the specification of the code from an implementation free perspective.

• When modifying code, always keep the commenting around it up to date.

• Comment should consist of complete sentences and follow active language naming responsibilities.

• Avoid adding comment at the end of a line of code. It is appropriate when annotating variable declarations. Align all end line comments at a common tab stop.

6. Declare variable in different lines (One declaration per line). Variable name should contain datatype type short character before variable name. (e.g.:- public string sUserName). Initialize variable where it is defined.*

7. Boolean variable names should contain 'Is' or 'is' which implies Yes/No or True/False values.

8. Constant should not be all uppercase with underscores between words. Constants follow the Pascal case naming convention. Variable name should contain datatype type short character followed by 'c' before variable name. (e.g.:- const int icNumDaysInWeek = 4 ;)

9. Temporary variables should always be used for one purpose only; otherwise, several variables should be declared.

10. Parameter names should follow the naming rules for variables.

11. No space between a method and the parenthesis.

12. Open brace and closing braces should be properly indented.

13. Methods are separated by two blank lines. Separate large methods to number of smaller methods. Follow doxygen compatible comments before every method.

14. If the body of the get or set method of a property consists of a single statement, the statement is written on the same line as the method signature. Property follows the pascal case naming convention. Property names should directly reflect the underlying attribute. Follow doxygen compatible comments before every property.

15. One blank line should always be used in following circumstances:

• Between the local variables in a method and its first statement.

• Between logical sections inside a method.

• After the closing brace of a block that is not followed by another closing brace.

16. Avoid names that expose the underlying implementation. A name should tell "What" rather than "How".

17. Instance fields and Object references are in camel case.

    (e.g.: protected string sOrderId ;)

For Application Architecture for .NET visit:-

https://msdn.microsoft.com/en-us/library/ff926074.aspx

Data Types Short character to be prefix:-

• Int - i

• String - s

• Byte - b

• Float - f

• Decimal - d

• Object - o

• Double - db

Doxygen Compatible comment convention :

Add Comments before every new Class, Method, Property, Structure etc.

• Comments will Start with /*! & End with */ .

• Use \class to describe block contains documentation for a class.

• Use \brief to add short description between comment start and end.

• Use \details to add detailed description between comment start and end.

• Use \param to add parameter description of method between comment start and end.

• Use \retval to describe a return value for a function.

• Use \todo to describe what is to be done.

For More Information on Doxygen read DoxygenCommanduse.doc file.

Coding standards for SQL Server:

Use uppercase characters for SQL keywords.

1. Indentation is constructed with spaces (4 spaces).

   Note: Set Tab with 4 spaces.

2. Conditional block will always start with BEGIN and ends with END.

3. Stored procedure, Views etc should follow naming convention as - TableName_ObjectType_Objectdetail.

   (e.g.: for stored procedure for Detail: Order_sp_detail)

4. Primary key will be always Integer datatype.

5. When naming tables, express the name in the singular form. When naming columns of tables, do not repeat the table name. Prefix data type short character before column name.

6. Do not prefix stored procedures with sp_, because this prefix is reserved for identifying system stored procedures

7. Generic table will named as TABLE1_TABLE2. (e.g.: Generic table of Product & Catalog will be like Product_ Catalog)

Data Types Short character to be prefix:-

• nVarchar - nvc

• Integer - in

• Decimal - dc

• Money - mn

• Float - fl

• Datetime - dt

• Bit - bt

• Don't use Varchar datatype.

DTS Process:

http://infostore.arcscorp.net/?p=153

Code Review Process:

http://infostore.arcscorp.net/?p=2430