LDSTechForumProjects

Code Standard for iOS

(Redirected from Code Standard)

Coding standard for iOS

Rules for the sake of rules are a waste. Nevertheless, a concise coding standard can be a great benefit as it makes it easy to read any code, and can formalize good practices which lead to fewer defects. By definition, a coding standard is arbitrary. Justifications for the rules are provided, but in many cases you can justify the opposite stance. The key is that we conform to the same set of rules, regardless of what their justifications are.

Our baseline coding standard is Coding Guidelines for Cocoa. The following rules clarify, expand on, or supercede Apple’s guidelines.


Prefixes

Application code should not be prefixed. Use the LDS (or other, as appropriate) prefix in code libraries.

Justification: Prefixes are a crufty namespace mechanism which should be used only when needed. Application classes and types are specific enough that they will tend not to conflict with third-party API, and can be easily changed where they do. Code libraries tend to use more generic names and are not easily changed when a conflict arises.


Enums

All enum values should be prefixed by the enum name:

typedef NS_ENUM(NSInteger, MyEnum) {
    MyEnumA 
    MyEnumB,
    MyEnumC,
};

Justification: You can paste the enum name and then immediately autocomplete in Xcode. It is also more obvious when reading code to which enum a value belongs.'


Line length

Try to keep lines shorter than 160 characters. You can set a preference in Xcode to draw a guide at this point in the editor.

Justification: It’s easier to read code that doesn’t wrap. Also we have wide screens these days.

Private interfaces

Put instance variables and protocol statements in the private (not the public) interface whenever possible:

@interface MyObject () <UITableViewDataSource> {
  NSString *value_;
}

@end

Justification: These are private implementation details.


If/else statements

Always use curly braces with if and if/else statements.

Justification: Omitting the braces decreases readability.


Curly braces

Place opening curly braces at the end of the line, not on a new line. For example:

if (...) {
    // ...
} else {
    // ...
}

Justification: This compresses the code, allowing more to be viewed on screen at once. This is a case of a rule where either way is equally valid, we just chose to standardize on this way.


Property declarations

Properties are always declared nonatomic. Use the following spacing:

@property (nonatomic, copy, readonly) NSString *property;

Justification: All properties are nonatomic because if you really need thread-safety, you almost certainly need something more. Explicit thread-safety mechanisms are more readable. As for the whitespace, it is more readable.


Asterisks

When declaring pointer types, whitespace should appear between the type and the asterisk. For example:

- (NSString *)methodWithArg:(NSString *)arg;


Blocks

When calling a method with more than one argument, one or more of which is a block, format it as follows:

[object
 retrieveObjectWithId:identifier
 withSuccessBlock:^(void) {
     // ...
 }
 andErrorBlock:^(NSError *error) {
     // ...
 }];

Justification: It results in lined up blocks, which are easier to read, and shorter lines, which don’t wrap.

Spaces

When using binary operators use spaces before and after the operator. For example: x+y becomes x + y

Switches

Switch statements should be formatted like so:

switch (a) {
    case 1:
        // ...
        break;
    case 2:
    case 3:
        // ...
        break;
    default:
        // ...
        break;
}

If you need a block, for example for a local variable, format it like this:

switch (a) {
    case 1: {
        // ...
        break;
    }
    case 2:
    case 3:
        // ...
        break;
    default:
        // ...
        break;
}

Justification: While not technically required, this mirrors the block structure used elsewhere.'

This page was last modified on 25 February 2013, at 11:58.

Note: Content found in this wiki may not always reflect official Church information. See Terms of Use.