Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The following are the standard set of spacing, formatting, and naming conventions we expect for Objective-C(++) code.

...

import vs.

...

include

Always #import Objective-C headers, and #include C (or C++) headers.

...

  • Objective-C classes are to be named with:
    • The prefix Ti, or another project-appropriate prefix
    • Camelcase
Code Block
titleExample

@interface TiExampleClass : NSObject {
// ivars
}

// properties

// methods

...

  • Protocols which reference a behavior type should end with a gerund (-ing).
  • Protocols which describe a set of actions should describe the functional property of these collective actions.
  • Protocols which are a delegate should end with the word Delegate.
Code Block
titleExample

@protocol TiScrolling; // Gerund; behavior type is "this object scrolls"
@protocol TiFocusable; // Action set; describes actions related to "focusing" and "TiFocusing" seems inappropraite ("this object focuses" vs. "this object performs actions related to focusing")
@protocol TiScrollViewDelegate; // Delegate

...

  • Methods should be named in camelcase, with the first character lowercase. Method names must never begin with an underscore.
  • The leading method specifier (+ or -) should not be followed by a space, and neither should the return type.
  • Selector (and argument) names should not have a space after their : character, or the type.
  • If method declarations, definitions, or calls are spread across multiple lines, their : characters should be aligned rather than spaced on tabstops.
  • The opening brace of a method should be on its own line for implementations.
Code Block
titleExample

+(void)x:(int)y
{
}

-(void)veryLongMethodName:(NSObject*)veryLongArgumentName
                     arg2:(NSObject*)anotherArg
                     arg3:(NSObject*)moreArg
{
}

...

  • Every class must have a designated initializer.
  • The following is the preferred way to assign to self in an init:
Code Block
titleExample

-(id)init
{
    if (self = [super init]) {
        // here...
    }
    return self;
}

...

  • Block variables should never be a raw type; they should always have a typedefassociated with them and that name used as the variable type.
    • EXCEPTION: The void (^varname)(void) block type does not require a typedef, although there are plenty of existing convenience typedefs for this block type which should be used when appropriate.
  • Blocks should have their opening brace on the same line as their ^, and their closing brace on its own line, indented with the surrounding scope.
  • Blocks have their contents indented one tabstop from the surrounding scope.
  • The void ^(void) block type should always be written as {{ ^{ ... } }}.
  • __block storage specifier objects should be used with care. Remember that if a __block variable goes out of scope when a block tries to access it, there can be unpredictable and bad results.
Code Block
titleExample

typedef int ^(intBlock)(int);

intBlock foo = ^(int foo) {
    return 2*foo;
};

...

Do not use the @compatibility_alias directive unless it is explicitly required due to a conflict between external libraries to a project, or multiple internal versions required by different 3rd party libraries.

...

pragma mark

Use #pragma mark liberally to annotate sections of your code where necessary, in addition to the rules spelled out above.