ObjC Coding Style Cheat Sheet (Version 1.0)

Compact version of the ObjC Coding Style, extending the C Coding Style Cheat Sheet.

1. Scope

• The standard C Coding Style Cheat Sheet remains authoritative for general formatting, naming, line breaking, comments, and control flow.
• This cheat sheet covers the Objective-C rules that add to the C rules.

2. Imports and File Structure

• Project headers first, framework imports next, C and system headers last.
• Prefer #import for Objective-C headers.
• Prefer @import for frameworks.

3. Interfaces, Protocols, and Categories

• Indent @interface, @protocol, and @implementation bodies by one level.
• If the superclass does not fit, break before :.
• If protocol conformance does not fit, break before < ... >.
• Use spaces after < and before > in protocol conformance lists.
• Interface order: properties, actions, initializers.
• Keep 2 blank lines between interface sections.
• If a section grows large, use: // ------------------------------------------------------------------------ // MARK: Section Name
• Keep 2 blank lines before such a marker and 1 after it.

4. Implementations and Ivars

• Indent @implementation contents by one level.
• Indent ivar blocks inside @implementation as well.
• Put the ivar block on the next indented level inside @implementation.
• Ivars always start with _.
• Prefer automatic property synthesis for normal properties.
• Do not add trivial getters or redundant ivars just to back a normal property.
• If synthesis must be explicit, prefer @synthesize propertyName = _propertyName;.
• Implementation order: ivars, deallocator, properties, actions, initializers, private actions, overrides, protocol sections.
• In protocol sections, keep: protocol properties, protocol actions, protocol initializers.
• Keep 3 blank lines between implementation sections when no marker is used.
• If a section grows large, use the normal marker form with 2 blank lines before and 1 after it.
• Declarations and definitions use spaces inside ( ).
• Calls do not use spaces inside ( ).
• Method { is on its own line.

5. Properties

• Keep short properties on one line.
• Single-line properties do not need blank lines between them.
• Use blank lines only to group related single-line properties.
• If a property must break, move the type and name to following lines.
• If properties are multi-line, leave one blank line between declarations.
• Use two blank lines between multi-line property groups.
• * belongs to the type, not the variable name.

6. Generics and Protocol-Qualified Types

• Generics use spaces around < and >.
• Protocol-qualified object types also use spaces around the protocol list.
• Normal pointer spacing rules still apply inside generics.

7. Method Declarations and Calls

• Normal C line-breaking rules still apply.
• Break after =.
• Break after (, [, or { when those delimiters start a broken expression.
• Indentation may decrease by at most one level between adjacent lines.
• Prefer keeping [ and ] on the same line if a send breaks only once.
• Place up to 3 arguments on one line for at most 2 lines.
• If more than 2 lines are required, place one argument per line.
• If a send breaks more than once, keep the receiver with [ on line one.
• Break long selectors along selector parts whenever possible.
• Keep return statements simple. Wrap non-trivial expressions in ( ).

8. Blocks

• Block declarations and definitions use spaces inside ( ), like functions.
• Calls do not use spaces inside ( ).
• In declarations and definitions, use a space after ^.
• Inline block literals do not use a space after ^.
• If a block literal fits on one line, it may stay on one line.
• If a block literal breaks, put { on its own line.
• For empty argument lists, write ^( ).
• If the call ends with the block, }]; may stay together.
• If the call continues, align the closing } with the continued call layout.

9. Vertical Spacing

• Keep two blank lines between method bodies.
• Keep three blank lines between implementation sections when no marker is used.
• Keep two blank lines between interface sections when no marker is used.
• If a marker groups methods or sections, use two blank lines before it and one after it.

10. Consistency Rule

• Consistency and readability still win.
• Match nearby code if it already follows these rules.
• If nearby code violates these rules, follow the guide for new or edited code.