Coding Standard:

• Always use camel case.

• Use prefix for every UI components like:

o TextField : txt<Name> like txtUserName, txtPassword
o TextView: txtv<Name>
o Label: lbl<Name>
o Table: tbl<Name>
o ImageVIew: img<Name>
o And so on…

• Use prefix for every Set

o NSDictionary: dict<Name>
o NSMutableDict: mdict<Name>

• Use #pragma mark - to categorize methods in functional groupings

and protocol/delegate

• Use of #define for all Web-API and should start with small “k” and
should be in camel case.

• Spacing
o Indent using 4 spaces (this conserves space in print and makes
line wrapping less likely). Never indent with tabs. Be sure to set
this preference in Xcode / Eclipse / ADT.
o Method braces and other braces (if/else/switch/while etc.)
always open on the same line as the statement but close on a
new line.
o There should be exactly one blank line between methods to aid
in visual clarity and organization.

• Class Name
o Class names are always capitalized.
o If it is connected with any view then the view name and a class
name should be same
o Class name should be <Name>Controller if connected with
view.
o Objective-C doesn't have namespaces, so prefix your class
names with initials.
o If you subclass a standard Cocoa Touch class, then combine
your prefix with the superclass name, such as FATableView. (FA
should be an initials for a project “FastAsk”. Its purely depend
on you for creating the initials for any project)

• Methods
o In method signatures, there should be a space after the method
type (-/+ symbol).
 o There should be a space between the method segments
(matching Apple's style).
o Always include a keyword and be descriptive with the word
before the argument, which describes the argument.

• Variables
o Variables should be named as descriptively as possible. Single
letter variable names should be avoided except in for() loops.
o Asterisks indicating pointers belong with the variable, e.g.,
NSString *text not NSString* text or NSString * text, except in
the case of constants.

• Property Attribute
o Property attributes should be explicitly listed.
o The order of properties should be storage then atomicity, which
is consistent with automatically generated code when
connecting UI elements from Interface Builder.

• Private Properties
o Private properties should be declared in class extensions
(anonymous categories) in the implementation file of a class.

• Comments
o When needed, comments should be used to explain why a
particular piece of code does something. Any comments that
are used must be kept up-to-date or deleted.

• Build Version #
o The very first version of the application should be started with
100 and incremental for further builds.