CODING STANDARDS & UNIT LEVEL CHECKLIST

CODING STANDARDS
Naming Conventions:-
1) camelCase should be followed for all ‘Variable’ declarations. Eg: $objUserArray
2) PascalCase should be used for Class names. Eg: $MyClass
3) All names should be in English and grammatically correct. Names like “foo” and
“tmp” should be avoided since they do not describe anything. Names should not
contain numbers, Numbers should be described with letters unless there is a good
reason for it.
4) Function names should also follow camelCase.
Eg:
setText(..);
id();
setID();
getTheValuesForThis();
Wherever applicable use name starting with ‘get’ or ‘set’ as and when the
functionality is to ‘get’ a value or ‘set’ a value respectively.
5) Constants should be constructed by only capital letters, ‘_’ should be used to separate
words.
Eg:
define( "MY_CONSTANT", 42 );
6) For Arrays, use the prefixes to denote the content type of the array and have the suffix
"Array" added. eg: $objUserArray

Indentation and Styles:-

1) For Braces {} use Unix styles of including the opening brace in the same line as the
expression. And there should be a space before the brace starts.
Eg:
public function generateAssetCode($intAssetId, $blnAssetFlag = true) {
...
return $strAssetCode;
}

Page 1 of 4
 CODING STANDARDS & UNIT LEVEL CHECKLIST

2) Single space is required after any comma. (Instances like comma separating
parameters in a function signature etc)
3) Empty lines should be used to group variables and code lines which have a
connection. Variable names which are grouped should be indented to the same level.
4) Prefer Ternary operator if it is a simple IF condition.
5) Nested if statements should always use {}. If you have a lot of ‘if, else’ statements
these should probably be replaced with ‘case’ statements.
6) Use Comments judiciously. Proper comment should be given for scripts, functions
and even variables if required.
Eg for Script:
/**
* Short description
* Multiple line detailed description.
* @project Fortuneprops
* @package xyz
* @author Your name here
* @version 1.0.0
*
*/
Eg for Method:
/**
* Generates an asset code based on AssetId
*
* @param integer $intAssetId This is the asset_id needed to generate the asset code
* @param boolean $blnAssetFlag This tells us if we're generating an asset code,
defaults true
* @return string $strAssetCode - This is the generated asset code
*/
public function generateAssetCode($intAssetId, $blnAssetFlag = true) {
...
return $strAssetCode;
}
7) Indent Consistently. Use indentation consistently to enhance the readability of the
code. When elements carry over more than one line of code, indent the contents of
Page 2 of 4
 CODING STANDARDS & UNIT LEVEL CHECKLIST

elements between the start tag and the end tag. This will make it easy to see where the
element begins and ends. Also, use indentation to align code at attribute names
8) Standard Tab size would be 4.

Code and Syntax:-

1) Functions should be short and do one thing. The length of a function depends on the
complexity of the function; the more complex the function is the shorter should the
function be. If it gets too complex then divide the function up into helper functions.
2) The number of local variables in a function should not be larger than 7, 7 is a known
limit to the number of things people can control at one time. Split up the function if it
gets too large.
3) SQL commands are written in all capital letters.
SELECT * FROM Person
WHERE ID=’$personID’
HAVING Age>’42’
LIMIT 0,20;
4) Table names should be in English. The names should be grammatically correct. Table
names with several words should be separated with “_” ( underscore). All letters
should be in lowercase. DO NOT use “-”(hyphen) to separate words.
The tables should be prefixed with the module name,
Eg: ezuser.
Example:
ezuser_user
ezarticle_category
eztrade_product_category_link

Page 3 of 4
 CODING STANDARDS & UNIT LEVEL CHECKLIST

UNIT LEVEL CHECKLIST

1) Image tags should have ‘alt’ and ‘title’ attribute.

2) Tab order should be proper. Preferably Left (Top to Down) then Right (Top to
Down).
3) All numeric fields should be right aligned.
4) Maxsize should be specified for an input box.
5) No two elements should have same ID in a document.
6) Mandatory fields in forms should have asterisk (*) and should be validated.
7) Date should follow a consistent format through the application.
Eg: MM/DD/YYYY
8) Numeric fields should be validated against the input of alphanumeric keys.
9) Error messages should be displayed in the same order of the fields in the Form.
10) Avoid grammatical mistakes for Labels and validation messages.
11) Validation messages should follow a similar pattern throughout the application.
12) Design should be tested for compatibility in Mozilla, IE7+, Safari and Netscape (if
required).
13) Mouse pointer symbol should be provided for all links and buttons.
14) All Delete/Cancel transactions should be validated with a Yes/No prompt using JS.
15) Contents in a Drop Down list should be alphabetically ordered.
16) The Default value ‘Select’ should be selected by default in every Drop Down list
unless otherwise required.
17) All HTML documents should have an appropriate ‘Title’.
18) All HTML documents should be check by a Validator (http://validator.w3.org/check )
. All Errors should be removed (including JS errors).
19) HTML code should always be written in lower case with the only exception being the
DOCTYPE
20) Consistently throughout the project meaningful words should be used.

Page 4 of 4