Coding Standards for SalesForce

1. One class per Visual Force page, Class name should be same as VF page name. Class name should be in noun, in Pascal case. Suffix 'cl' after class name. (e.g.: class SalesForcecl ;).

2. Minimum Code coverage should be 75% of Creating/modifying Apex class and trigger.

3. Use Try catch block wherever required, blank catch not allowed except test classes.

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

   Note: Set Tab with 2 spaces For VF page as well as for Apex Class.

5. When an expression will not fit on a single line, break it after an operator OR a comma OR indent once after a break to Avoid left Scrolling. There should be no Left Scrolling on VF page And Apex class and trigger etc.

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, null initialization not allowed except Id variable.

7. Null check should be there for each variable type.

8. Null and size check should be there for each list variables type before using it.

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

10. Use Transient key word for all variables if it is not required to mange view state.

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

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.

14. 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.

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

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

    (e.g.: private string sOrderId ;)

Data Types Short character to be prefix:-

• Integer - i

• String - s

• boolean - bIs

• Decimal - d

• Object - o

• Double - db

• list - Lst

Coding standards for SOQL :

1. Use uppercase characters for SOQL keywords.

2. When naming Object, express the name in the singular form. When naming columns of objects, do not repeat the object name.

3. Generic Object will named as Object1_Object2. (e.g.: Generic Object of Order & Item will be like Order_Item)

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.

DTS Process:

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

1. Ticket Should be Set on Feedback after QA testing if there is no code changes made by Developer.

2. Testing Template need to be approved by Manager.

3. You Need to send an e-mail to Anshu Sir before one day of ETA expiration if you seems that you cannot complete the task within given ETA by providing valid reason like you are busy in top priority task etc. and when you will be able to complete it.**

Code Review Process:

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