Guidelines

These are the "guidelines" that we should follow.

CoreData

This is an example project that uses core data the same way it's set up to be used in this project.

Security

Use NSSecureCoding when appropriate.

Strings

Use NSAttributedString when displaying text to users.

Class Declarations

@implementation ClassName
{

}

• Classes should have inline style braces for local variable declarations

Interface/Protocol Declarations

• Newline after @interface/@Protocol and before @end

Method Declarations

- (void)methodName:(id)param moreOfMethodName:(id)param

• Space after the class/instance identifier
• No space after return type
• Camel case starting with a lowercase for names of methods
• Method names should clearly express the functionality of method thus removing ambiguity

Property Access

self.view.hidden = YES;

is preferred to

[self.view setHidden:YES];

Blocking

// Methods
+ (instanceType)new
{

}
// For, if, else block etc...
for (int i = 0; i < 10; i++) {

}

• If the block's a method, the braces should be inline, otherwise Egyptian
• For Egyptian style there should be a space before the opening bracket

Loops and Conditionals

• Space after for/if before condition
• No space inside ()
• Space after ; inside for loop

Variables

• Method parameters should start with lowercase and be no more than two words
• Method parameters should be camelcase
• Properties should start with a lowercase and be camel case
• Properties should be accessed with the _ syntax
• Properties in the header are expected to be publicly used and should be documented, if they should be private they can be declared in a class extension in the .m file
• Private instance variables should be declared in the .m file
• Private instance variables should start with an _

Documentation

• Public methods should be documented in the header:

/**
 * Your description will go here, the first 80 characters should be
 * brief and quickly describe functionality.
 *
 * Any further description should be one return below the description
 * and will cover more in-depth usage examples.
 * 
 * @param number - Use @param to describe parameters
 * @return describe the return value
 */
 - (NSString *)myMethod:(NSInteger)number;

• Properties should provide a brief description in the same format
• Inline comments should provide clarity to anything that may be ambiguous; code should be broken up well enough that lines shouldn't need additional explanation beyond method names

Any questions regarding clarification can be expressed in the discussion issue #89

Testing

Relationships

Relationships and connections between classes shouldn't break

Setup

Instantiate classes consistently (this will prevent unwanted behavior).

Naming

Name all test classes ClassnameTest.m
Avoid renaming methods. If needed use Xcode's redaction tools.

Usage

Still using SenTesting in an effort to continue support of iOS 6.

Debugging

Steps to debugging:

1. Make sure you're up to date on a stable commit (git bisect is your friend!)
2. Clean build
3. Rebuild
4. Breakpoints!
5. Bootcycle Xcode
6. Re-clone project

Weird bugs we've found

• -debugiphoneos: needed to reclone project