Ios coding standard

Coding Standard
Names
●? Names of classes, methods and important variables should be chosen with care, and should be meaningful.


Code|Commentary|
insertObject:atIndex:|good|
insert:at:|not clear; what is being inserted? what does “at” signify?|
removeObjectAtIndex:|good|
removeObject:|also good, because it removes object referred to in argument|
remove:|not clear; what is beingremoved?|


●? Abbreviations are to be avoided, except where they are widely accepted. If possible, document those that are crazy small names.

Code|Commentary|
destinationSelection|good|
destSel|not clear|
setBackgroundColor:|good|
setBkgdColor:|not clear|


●? Use names that are in English are self-descriptive and that you can pronounce.
●? Avoid:
○? Names that sound very similar
○?Numbers in names
○? Misspelled names (hilite vs highlight)
○? Do not use same name with different capitalization.
Files
●? Use one file per class, with the filename matching the name of the class, for easier retrieval.
●? Files names use PascalCase and add a prefix which identifies the project in order to differentiate the generic code of the application code. For example, all classes must bestart with DA in the project DoodleAirStrike like DAMainScene. If you are working in Nextive's framework, your class name must start with NX prefix like NXName.
Class
●? Class names use the same criteria as files names, as they should be the same.
●? The first method in .m file must be “dealloc”, so it’s easier to check that all variables are release. If you have an empty “dealloc” method, adda comment explaining that you don’t have variables to release.
○? There preferred way to release a variable is this:

[_x release];
_x = nil;
Methods
●? Methods names use camelCase.
●? Do not add methods which only call the base method, with the exception of dealloc.
●? A method must contain at most something like 30 lines of code, if it contains more, try thinking ofrefactoring it.
●? I know that nowadays we have wide screens and stuff, though code with more than 160 columns is not OK. Makes me scroll to the right. Try having a maximum of 110-130 columns.
●? Use return/enter to separate code blocks.
●? Do not use the "get" prefix for the getter, just the variable name.
●? Use always NARC convention. If you invoked a method that contains New, Alloc, Retain, orCopy, then you must release it.
Variables and Properties
●? Variables names use camelCase. Instance variables must have underscore as prefix.
●? For temp variables, also use significant names, though when iterating over an array, i and j are just fine..
●? Constant variables use ALL_CAPS_WITH_UNDERSCORES.
●? If possible, do not re-use the same variable over and over again. Bug Prone?
●? Do notuse index as variable name, as C has got that function name already defined, and in some obscure cases it might overlap.
●? Use constants instead of magic numbers.
●? Add only the properties that you use.
●? Properties have the same name as the instance variables they wrap, minus the underscore.
●? When using @synthesize, use one line per property, as the following example shows:
@synthesizefirstNameLabel;
@synthesize lastNameLabel;
@synthesize emailLabel;
This way, if the property is for a different variable (for example one with an underscore), you can write it as this:
@synthesize firstNameLabel = _firstNameLabel;
@synthesize lastNameLabel = _lastNameLabel;
@synthesize emailLabel = _emailLabel;
Comments
●? Keep the comment updated. If you modify a method, you must modifythe comment also.
●? Do not comment self-descriptive code.
●? Only comment the following cases:
○? To explain “How or what it is used for”.
○? To explain “Why it is resolved in this way”.
Asserts
●? The sooner you identify the problem the better for you.
●? Prefer using assert to using comment. It doesn’t help to manage the user error, but it helps to prevent programming errors.
●?...