{"id":18389334,"url":"https://github.com/rightpoint/raizlabs-cocoa-style","last_synced_at":"2026-03-15T04:31:20.907Z","repository":{"id":19514312,"uuid":"22761186","full_name":"Rightpoint/Raizlabs-Cocoa-Style","owner":"Rightpoint","description":"The Raizlabs iOS Style Guide","archived":false,"fork":false,"pushed_at":"2019-03-19T20:49:11.000Z","size":1197,"stargazers_count":32,"open_issues_count":34,"forks_count":2,"subscribers_count":34,"default_branch":"master","last_synced_at":"2025-03-22T11:43:49.193Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Objective-C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Rightpoint.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-08-08T14:52:48.000Z","updated_at":"2022-06-07T16:59:37.000Z","dependencies_parsed_at":"2022-08-23T17:20:25.220Z","dependency_job_id":null,"html_url":"https://github.com/Rightpoint/Raizlabs-Cocoa-Style","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Rightpoint%2FRaizlabs-Cocoa-Style","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Rightpoint%2FRaizlabs-Cocoa-Style/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Rightpoint%2FRaizlabs-Cocoa-Style/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Rightpoint%2FRaizlabs-Cocoa-Style/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Rightpoint","download_url":"https://codeload.github.com/Rightpoint/Raizlabs-Cocoa-Style/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247583356,"owners_count":20962024,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-06T01:42:40.377Z","updated_at":"2025-12-18T01:52:44.590Z","avatar_url":"https://github.com/Rightpoint.png","language":"Objective-C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Raizlabs Objective-C Style Guide\n\nThis guide outlines the coding conventions and best practices for the Objective-C developers at Raizlabs.\n\n\u003c!-- START doctoc generated TOC please keep comment here to allow auto update --\u003e\n\u003c!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --\u003e\n**Table of Contents**  *generated with [DocToc](http://doctoc.herokuapp.com/)*\n\n- [Dot Syntax](#dot-syntax)\n- [Whitespace](#whitespace)\n  - [Newlines](#newlines)\n  - [Indentation](#indentation)\n- [Naming](#naming)\n  - [Variables](#variables)\n  - [Properties](#properties)\n  - [Instance Variables](#instance-variables)\n  - [Constants](#constants)\n- [Variables](#variables-1)\n- [Properties](#properties-1)\n- [Conditionals](#conditionals)\n- [Mathematical operators](#mathematical-operators)\n- [`CGFloat`](#cgfloat)\n- [Switch statements](#switch-statements)\n- [Comments](#comments)\n- [Method Signatures](#method-signatures)\n- [Return statements](#return-statements)\n- [Protocols](#protocols)\n- [Blocks](#blocks)\n  - [Naming](#naming-1)\n  - [Spacing](#spacing)\n  - [Block Parameters](#block-parameters)\n- [Constants](#constants-1)\n  - [User-Facing Strings](#user-facing-strings)\n  - [Other string constants (non-user-facing)](#other-string-constants-non-user-facing)\n  - [Magic Strings](#magic-strings)\n  - [Numbers](#numbers)\n  - [Structs](#structs)\n- [Enumerations](#enumerations)\n- [Initializers](#initializers)\n- [Singletons](#singletons)\n- [Error handling](#error-handling)\n  - [Out Errors (`NSError **`)](#out-errors-nserror-)\n- [Literals](#literals)\n- [Rule of three](#rule-of-three)\n  - [Protocol Conformation](#protocol-conformation)\n  - [Method calls/signatures](#method-callssignatures)\n- [Unnecessary code](#unnecessary-code)\n- [File Organization](#file-organization)\n  - [Header Files (`.h`)](#header-files-h)\n    - [When to use a `_Private.h` file](#when-to-use-a-_privateh-file)\n  - [Implementation Files (`.m`)](#implementation-files-m)\n\n\u003c!-- END doctoc generated TOC please keep comment here to allow auto update --\u003e\n\n## Dot Syntax\n\nUse dot notation for all property access and manipulation. **Never** access `_ivars` directly when a property has been declared, except where required:\n\n**Preferred:**\n\n```objc\nself.foo = 4;\nint bar = self.foo;\n```\n\n**Not:**\n\n```objc\n[self setFoo:4];\nint bar = [self foo];\n_bar = 4;\n```\n\nFor clarity, you may use bracket notation for overridden setters/getters:\n\n```objc\n- (void)setFoo:(int)foo\n{\n    // some extra code goes here\n\n    _foo = foo;\n}\n\n- (int)foo\n{\n    // some extra code goes here\n\n    return _foo;\n}\n\n- (void)aMethod\n{\n    [self setFoo:4];\n    int test = [self foo];\n}\n```\n\n**Never** use dot notation on a non-[idempotent](http://en.wikipedia.org/wiki/Idempotent) property or method. For example, `count` isn't actually a property on `NSArray`; the compiler just infers because there's a method called count. However, it *is* an idempotent method, so it is safe to use dot-notation:\n\n```objc\nNSUInteger foo = myArray.count;\n```\n\nAvoid non-idempotent setters\n\n**Bad:**\n\n```objc\n- (void)setFoo:(id)foo\n{\n    _foo = foo;\n    _lastTimeFooWasSet = [NSDate date];\n   [self.tableView reloadData];\n}\n```\n\n**Better:**\n\n```objc\n- (void)updateFoo:(id)foo refresh:(BOOL)refresh\n{\n    self.foo = foo;\n    if ( refresh ) {\n        _lastTimeFooWasSet = [NSDate date];\n        [self.tableView reloadData];\n    }\n}\n```\n\nThis is not to say that you shouln't override setters; you just need to be careful that the side effects are obvious, and with low potential danger.\n\n## Whitespace\n\n### Newlines\n\n- Never more than one consecutive newline of whitespace\n- Use one newline of whitespace to group conceptually distinct parts of methods.\n\n```objc\n- (void)viewDidLoad\n{\n    // set up foo object\n    UIFoo *foo = [[UIFoo alloc] init];\n    foo.property = value;\n\n    // set up bar object\n    UIBar *bar = [[UIBar alloc] initWithThing:foo];\n}\n```\n\n### Indentation\n\n- Always use 4 spaces, never tabs. (In Xcode, go to **Preferences** → **Text Editing** → **Indentation** to set this.)\n\n## Naming\n\n### Variables\n\nVariables always use camel case:\n\n```objc\nlikeThis;\n```\n\nVariables of type `Class` start with a capital letter. Note that a variable of type `Class` should use `Nil`, not `nil`, to express emptiness:\n\n```objc\nClass SomeClassVariable = Nil;\nSomeClassVariable = [MyClass class];\n```\n\n### Properties\n\nNever give properties generic names. Instead, prefix the variable name with a descriptor such as, but not limited to, the class name.\n\n**Preferred:**\n\n```objc\n@property (strong, nonatomic) UICollectionView *myClassCollectionView;\n```\n\n**Not:**\n```objc\n@property (strong, nonatomic) UICollectionView *collectionView;\n```\n\n### Instance Variables\n\nInstance variables begin with an underscore and rename the variable to `_propertyName`.\n\n```objc\n@synthesize ivarName = _ivarName;\n```\n\nHowever, the use of explicitly declared or synthesized instance variables is discouraged except where required.\n\n### Constants\n\nConstants are camel-case, and should use the following format:\n\n- lowercase `k` prefix\n- followed by the project's class prefix in all caps\n- followed by class name\n- followed by descriptor\n\n```objc\n// [k][class prefix][class name][constant name]\nstatic const NSInteger kRZMyClassSomeErrorCode = -1;\n```\n\nSee also: [Cocoa naming conventions for variables and types](https://developer.apple.com/library/mac/documentation/cocoa/conceptual/codingguidelines/articles/namingivarsandtypes.html).\n\n## Variables\n\nAsterisks indicating pointers belong with the variable, except in the case of [constants](#constants):\n\n**Preferred:**\n\n```objc\nNSString *text;\n```\n\n**Not:**\n\n```objc\nNSString* text;\nNSString * text\n```\n\nAlways use `@property`-declared variables instead of instance variables (except for where you have to).\n\n**Preferred:**\n\n```objc\n@interface RWTTutorial : NSObject\n\n@property (copy, nonatomic) NSString *tutorialName;\n\n@end\n```\n\n**Not:**\n\n```objc\n@interface RWTTutorial : NSObject\n{\n    NSString *tutorialName;\n}\n```\n\nInstance variables are required in the following case:\n\n\u003e Subclasses don't have visibility into auto-synthesized properties defined on ancestor classes. Redefining the property requires duplicating the property semantics, which might change. Declaring the instance variable is actually correct in this case. If you want to hide it, mark it `@private` or use a private header.\n\n## Properties\n\n- Spaces between `@property`, specifiers, and property type\n- Asterisk sticks to property name\n- Specifier order:\n\n 1. Retain strength: `strong`, `weak`, `assign`, `copy`\n 2. Atomicity `nonatomic`, `atomic`\n 3. Readability `readwrite`, `readonly`\n 4. Custom getter\n 5. Custom setter\n\n**Preferred:**\n\n```objc\n@property (strong, nonatomic) NSObject *someObject;\n```\n\n**Not:**\n\n```objc\n@property (nonatomic, strong) NSObject *someObject;\n@property (strong, nonatomic) NSObject* someObject;\n@property (strong, nonatomic) NSObject * someObject;\n@property(strong, nonatomic) NSObject *someObject;\n@property(strong, nonatomic)NSObject *someObject;\n```\n\n## Conditionals\n\n- **NEVER** forgo the braces for one-line if statements ([#gotofail](https://www.imperialviolet.org/2014/02/22/applebug.html) anyone?)\n- One space between the control keyword and opening parentheses\n- Opening brace same line as predicate, separated by one space\n- Continuing keywords (`else if`/`else`) on new line below closing brace\n- All keywords and closing braces are flush left and code within braces are indented 4 spaces\n\n**Preferred:**\n\n```objc\nif (expression) {\n    // if code\n}\nelse if (other expression) {\n    // else if code\n}\nelse {\n    // else code\n}\n```\n\n**Not:**\n\n```objc\nif ( expression )\n{ // shouldn't be on next line\n    // if code\n} else if ( expression ) // else should start on new line\n{\n    // else if code\n}\nelse\n    // else code // NEVER forgo braces\n```\n\n## Mathematical operators\n\nUnary operators stick to the number they modify:\n\n```objc\nint x = -10;\nNSNumber *y = @(x * -3);\n```\n\nUse spaces between all binary and ternary mathematical operators. Fully parenthesize mathematical expressions and any logical expression with 1+ operator:\n\n```objc\nint x = ((1 + 1) / 1);\n```\n\nTernary conditional tests must be enclosed in parens:\n\n```objc\nCGFloat result = (x \u003e 2) ? someValue : otherValue;\n```\n\nNon-conditionals do not need parens:\n\n```objc\nCGFloat result = self.isLoading ? someValue : otherValue;\n```\n\nNo nesting of ternary expressions.\n\n- Don't even think about it.\n\n```objc\nBOOL dontDoThis = self.otherBOOL ? ((self.dont) ? self.do : self.this) : self.please;\n```\n\n## `CGFloat`\n\n- `CGFloat` is defined as `double` in 64-bit architecture and `float` in 32-bit\n- Always trail with an `f` when sending a float literal to a `CGFloat` parameter\n- Do not use `x.f` when there is no decimal value. Instead, use `x.0f`\n    - Although `x.f` compiles perfectly fine, it is unclear (especially for our clients who may not be used to this abstract notation)\n\n**Preferred:**\n```objc\nCGSizeMake(2.0f, 2.0f);\n```\n\n## Switch statements\n\n-  Braces should be on same line as `case`\n-  If a case has more than one line of code (other than the break), surround that case's body with braces\n-  Spaces inside parentheses, just like conditional statements\n\n```objc\nswitch ( expression ) {\n    case 1:\n        // code\n        break;\n    case 2: {\n        // code\n        // code\n        break;\n    }\n\n    default:\n        // default code\n        break;\n}\n```\n\nWe strongly encourage you to put fallthroughs at the **end** of the statement:\n\n```objc\nswitch ( expression ) {\n    case 1: {\n        // case 1 code\n        break;\n    }\n    case 2: // fall-through\n    case 3:\n        // code executed for values 2 and 3\n        break;\n    default:\n        // default code\n        break;\n}\n```\n\nDo not use a default if there isn't any handling for the default case:\n\n**Preferred:**\n\n```objc\nswitch ( expression ) {\n    case 1: {\n        // case 1 code\n        break;\n    }\n    default: {\n        // default code\n        // more default code\n        break;\n    }\n}\n```\n\n**Not:**\n\n```objc\nswitch ( expression ) {\n    case 1: {\n        // case 1 code\n        break;\n    }\n    default: // nothing here, no need for default!\n        break;\n}\n```\n## Comments\n\n- Comment whenever you are mitigating an OS bug (including the OS revision and when it might be able to be removed, if you know)\n- Comment whenever you write code that might appear weird or intimidating to a new developer\n- In general, comment any nontrivial code\n- Don’t comment trivial code where the meaning should be inferred from good variable and method naming\n\n- Never use your name in comments or code\n    - It isn't a good idea to send that info to clients\n    - It isn't necessary, beacuse of `git blame`\n\n- Never reference bug numbers from another bug tracker (Jira, Github) in code\n\n- Use double slash comments (`//`)\n\n    - One space always immediately after slashes\n\n    - In general, put comments on the line before the code being explained. One newline should come before the comment and after the code fragment being explained to avoid confusion with following code unrelated to comment:\n\n```objc\n...preceding code...\n...preceding code...\n\n// Explanatory comment\n...code being explained...\n\n...other code unrelated to comment...\n...other code unrelated to comment...\n```\n\n- You _may_ comment \"trivial\" code if it aids readability in some way (eg. visually distinguishing multiple tasks in a long method)\n- You _may_ comment in-line where appropriate. Eg. to identify the closing brace of a nested code block.\n\n    - Special comment identifiers\n\n        - `// !!!:`\n\n            - Use to comment code that mitigates OS bugs, code that could in the future be eliminated or changed when something out of our control is fixed\n\n        - `// ???:`\n\n            - Do not use (?)\n\n        - `// TODO:`\n\n            - Use when code is committed but is intentionally left incomplete, i.e. empty method bodies whose implementation is part of another sprint-planned issue\n\n- `/* */`\n\n    - Very long comments (3 lines or more; see [Rule of Threes](#rule-of-three))\n\n- `/** */` Documentation Comments\n\n    - Documentation comments give semantic and contextual meaning to our APIs\n\n    - These are required for open-source frameworks, but can also be useful to document internal code, especially core components of an app, like common API and data classes\n\n    - Can be parsed by [AppleDoc](http://gentlebytes.com/appledoc/) to create documentation file from code\n\n    - Use `///` *only* for 1-line documentation comments\n\n    - Install [VVDocumenter](https://github.com/onevcat/VVDocumenter-Xcode) via [Alcatraz](https://github.com/onevcat/VVDocumenter-Xcode) to automatically fill in AppleDoc-style comments when you type `///`\n\n    - For more info on documentation in Xcode, see [this stackoverflow answer](http://stackoverflow.com/a/6605536)\n\n## Method Signatures\n\n- One space between scope symbol (`-`, `+`) and return type\n- One space between types and asterisks\n- Descriptive names for parameter names\n- A pre-colon identifier must be present for each parameter\n- A type must be present for each identifier\n- Don't use `and` or `or` for parameter names.\n- Block parameters should always be last\n\n**Preferred:**\n\n```objc\n- (NSObject *)methodNameWithParam:(NSObject *)param otherParam:(NSObject *)otherParam;\n```\n\n**Not:**\n\n```objc\n- (NSObject *)methodNameWithParam:(NSObject *)param andOtherParam:(NSObject *)otherParam;\n-(void)setT:(NSString *)text i:(UIImage *)image;\n- (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag; // Never do this\n- (id)taggedView:(NSInteger)tag;\n- (instancetype)initWithWidth:(CGFloat)width andHeight:(CGFloat)height;\n- (instancetype)initWith:(int)width and:(int)height; // Never do this.\n```\n\nColon-align long method signatures ([3 lines or more](#rule-of-three)) (unless there is a block parameter!):\n\n```objc\n- (id)initWithTableView:(UITableView *)tableView\n         collectionList:(id\u003cRZCollectionList\u003e)collectionList\n               delegate:(id\u003cRZCollectionListTableViewDataSourceDelegate\u003e)delegate\n```\n\nWhen the first parameter is not as long as the latter ones, left-align all lines. (This is what Xcode’s default auto-format behavior, so it runs the least risk of being changed by mistake later.)\n\n```objc\n- (void)align:(BOOL)this\nveryVeryVeryVeryLong:(BOOL)method\nsignatureThatIsStillNotAsLongAsManyTotallyLegitimateCocoa:(BOOL)methods\n```\n\nSee also: [Cocoa naming conventions for methods](https://developer.apple.com/library/mac/documentation/cocoa/conceptual/codingguidelines/Articles/NamingMethods.html).\n\n## Return statements\n\nUsing only one return at the end of a method end is **extremely preferred**. Instead of bailing early, modify a return variable within the method:\n\n**Preferred:**\n\n```objc\n- (int)foo\n{\n    int ret = 0;\n\n    // code to modify \"ret\"\n    switch ( self.bar ) {\n        case 0: {\n            ret = 12;\n            break;\n        }\n        case 1: {\n            ret = 42;\n            break;\n        }\n        default:\n            // handle default case\n            ret = 11;\n            break;\n        }\n    }\n\n    return ret;\n}\n```\n\n**Not:**\n\n```objc\n- (int)foo\n{\n    switch ( self.bar ) {\n        case 0:\n            return 12;\n        case 1:\n            return 42;\n        default:\n            return 0;\n    }\n}\n```\n\nEarly returns are permitted only at the beginning of a method, when you need to bail quickly:\n\n```objc\n- (id)doSomething\n{\n    if ( doingSomething ) {\n        return nil;\n    }\n\n    // do awesome things\n    return awesomeThing;\n}\n```\n\n## Protocols\n\n- Protocol name should be of the format [`class prefix`][`class name`][`protocol function`]\n- Forward protocol declaration appears before `@interface` definition; protocol definition comes after.\n- The delegate property in the interface should be `weak`.\n- `@required` and `@optional` only need be present if both types of methods exist. If they are both omitted, every method is required by default.\n\n**Preferred:**\n\n```objc\n@protocol RZSomeClassDelegate;\n\n@interface RZSomeClass : NSObject\n\n@property (weak, nonatomic) id \u003cRZSomeClassDelegate\u003e delegate;\n\n@end\n\n@protocol RZSomeClassDelegate \u003cNSObject\u003e\n\n@required\n\n// required methods\n\n@optional\n\n// optional methods\n\n@end\n```\n\n**Not:**\n\n```objc\n@protocol RZSomeClassDelegate \u003cNSObject\u003e\n\n@required\n\n// required methods\n\n@optional\n\n// optional methods\n\n@end\n\n@interface RZSomeClass : NSObject\n\n@property (weak, nonatomic) id \u003cRZSomeClassDelegate\u003e delegate;\n\n@end\n```\n\n## Blocks\n\nIf you can do it with with a completion block, don't use a protocol.\n\n### Naming\n\n- `typedef` blocks that are specific to a class or function\n- `typedef`ed names should follow the [constant naming protocol](#naming)\n\n```objc\n// some .h file\ntypedef void (^RZCompletionBlock)(BOOL succeeded, NSError *error);\n```\n\nDo not use a newline before the opening curly brace.\n\n**Preferred:**\n\n```objc\n[UIView animateWithDuration:0.2 animations:^{\n    // animation code\n} completion:nil];\n```\n\n**Not:**\n\n```objc\n[UIView animateWithDuration:0.2\n                animations:^\n                {\n                    // animation code\n                } completion:nil];\n```\n\n### Spacing\n\nWhen the block takes parameters, put a space between the closing parenthesis and the the opening curly brace:\n\n```objc\n[self.thing enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {\n    // code\n}];\n```\n\nWhen the block takes **no** parameters, do not put a space between  the `^` and the `{`:\n\n```objc\n[UIView animateWithDuration:9.41 animations:^{\n    // code\n}];\n```\n\n### Block Parameters\nWhen you don’t want to pass a block to a parameter, use `nil`, not `NULL`. This is because blocks are Objective-C objects, and because you may want to send messages such as `-copy` to them even if they are `nil`.\n\n```objc\n[self presentViewController:aViewController\n                   animated:YES\n                 completion:nil];\n```\n\n## Constants\n\n### User-Facing Strings\n\n**Always** use NSLocalizedString for User-facing strings.\n\n- These need not be in a separate header. They can be defined at the top of the file that uses them.\n- **Always** `#define` NSLocalizedString constants.\n\n**Preferred:**\n\n```objc\n#define kRZClassNameStringConstant NSLocalizedString(@\"Hello World\", @\"A hello world string\")\n````\n\n### Other string constants (non-user-facing)\n\n- Do not use `#define`\n    - FYI: **When you #define a constant, it's defined in every other file the compiler looks at until (if) it's `#undef`ed. It could also be redefined at any time.**\n\n- **Always** use static or extern string constants\n- use `OBJC_EXTERN` instead of `extern`\n- use reverse-domain syntax with the domain of the project for internal (non-user-facing and non-api-facing) string constants\n\n**Preferred:**\n\n```objc\nstatic NSString* const kRZLoginUsername = @\"com.raizlabs.login.username\";\n```\n\nIf you want to make it **public**, put this in the `.h` file:\n\n```objc\nOBJC_EXTERN NSString* const kRZLoginUsername;\n```\n\nAnd in the `.m`:\n\n```objc\nNSString* const kRZLoginUsername = @\"com.raizlabs.login.username\";\n```\n\n### Magic Strings\n\n- **NEVER use them!**\n\n    - i.e. never do this:\n\n```objc\n- (void)someMethod\n{\n    NSString *message = @\"Error, you broke the app!\";\n}\n```\n\n### Numbers\n\n- Do not use `#define`\n- Use static or extern number constants\n    - This hides the actual value from public interfaces, so programmers are more likely to use the constant instead of copying the value\n\n**Preferred:**\n\n```objc\n// .m file\nconst int intName = 4;\n\n// .h file\nOBJC_EXTERN const int intName;\n```\n\n**Always** make internal, private constants `static`.\n\n**Preferred:**\n\n```objc\n// .h file\n// This space intentionally left blank\n\n// .m file\nstatic const CGFloat buttonHeight = 44.0f;\n\n```\n\nMagic numbers are allowed for numbers that can't change (like dividing by 2 to get the center of something)\n\n### Structs\n\nIf you need a constant struct, use the [designated intializer syntax](https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html):\n\n```objc\nstatic const CGSize kRZTestViewControllerShadowOffset = { .width = 0.0f, .height = 3.0f };\n```\n\n## Enumerations\n\n- **Always** use `NS_ENUM` (see [this NSHipster post](http://nshipster.com/ns_enum-ns_options/))\n- Always define the numeric value of the first item\n\n**Preferred:**\n\n```objc\ntypedef NS_ENUM(NSInteger, RZFoo) {\n    RZFooBlue = 0,\n    RZFooRed,\n    RZFooGreen\n};\n```\n\n**Not:**\n\n```objc\ntypedef enum\n{\n    RZFooBlue,\n    RZFooRed\n    RZGreen\n}RZFoo;\n\nenum\n{\n    RZFooBlue,\n    RZFooRed\n    RZGreen\n};\n\n```\n\n- The name of the type should act as a prefix for the subtypes\n\n- Typedefs should have class prefixes\n\n- It is common to use an \"Unknown\" type. If present, it should always be the first item in the enum.\n\n**Example:**\n\n```objc\ntypedef NS_ENUM(NSInteger, RZFoo) {\n    RZFooUnknown = -1,\n    RZFooBlue,\n    RZFooRed\n};\n```\n\nIf you want to accept mutilple sub-values, use a bitmask\n    - Always use an **unsigned integer** for bitmasks\n\nAdd an \"All\"-suffixed subtype when applicable\n\n**Example:**\n\n```objc\ntypedef NS_OPTIONS(NSUInteger, RZFoo) {\n    RZFooUnknown,\n    RZFooBlue,\n    RZFooRed,\n    RZFooGreen,\n    RZFooAll\n};\n```\n\n## Initializers\n\n- Return `instacetype`, not `id`.\n- Use `[[[self class] alloc] init]` when instantiating an object of same type as `self`, so that subclasses that call these methods will get back an object of the correct class.\n\n**Preferred:**\n\n```objc\n- (instancetype)init;\n```\n\n**Not:**\n\n```objc\n- (id)init;\n```\n\n## Singletons\n\nSingleton objects should use a thread-safe GCD pattern for creating their shared instance:\n\n```objc\n+ (instancetype)sharedInstance\n{\n    static id sharedInstance = nil;\n\n    static dispatch_once_t onceToken;\n    dispatch_once(\u0026onceToken, ^{\n        sharedInstance = [[[self class] alloc] init];\n    });\n\n   return sharedInstance;\n}\n```\n\n## Error handling\n\n**Always** handle errors and return values\n\n- check `BOOL` or object return value before checking the error inout parameter\n\n- The parameters of completion blocks should include a success `BOOL` when applicable (e.g. web service calls). Test against this `BOOL`, not the `error` object, to determine whether the operation was successful\n- It is **never** safe to assume that a method will return a valid error object without first checking the return value, especially when using Apple APIs\n\n**Preferred:**\n\n```objc\n- (void)doSomething\n{\n    [someObject doSomethingWithCompletion:^(BOOL success, NSError *error) {\n        if ( success ) {\n            // Handle success\n        }\n        else if ( error ) {\n            // Handle error with an error object returned\n        }\n        else {\n            // Handle error without an error object\n        }\n    }];\n}\n```\n\n**Not:**\n\n```objc\n- (void)doSomething\n{\n    [someObject doSomethingWithCompletion:^(BOOL success, NSError *error) {\n        if ( error ) {\n            // Handle error\n        }\n        else {\n            // Assume success\n        }\n    }];\n}\n```\n\nName error pointers something more specific than `error` when there are nested/multiple calls that return errors in the scope of a method\n\n**For example:**\n\n```objc\n// Ignoring above advice about checking return value\n// for the sake of a concise example.\n- (void)doColor\n{\n    [self blueWithError:^(NSError *blueError) {\n            if ( blueError ) {\n                // handle blueError\n            }\n\n            [self redWithError:^(NSError *redError) {\n                if ( redError ) {\n                    // handle redError\n                }\n            }];\n        }];\n\n    [self yellowWithError:^(NSError *yellowError) {\n        if ( yellowError ) {\n            // handle yellowError\n        }\n    }];\n}\n```\n\n### Out Errors (`NSError **`)\n\n- Methods that return errors should return an object or a `BOOL` indicating success\n- Always name `NSError` double pointers `outError`:\n\n```objc\n- (BOOL)doActionReturningError:(NSError **)outError;\n- (BOOL)doActionWithThing:(NSObject *)thing error:(NSError **)outError;\n```\n\n## Literals\n\nUse [Objective-C literals](http://clang.llvm.org/docs/ObjectiveCLiterals.html) wherever possible.\n\n**Preferred:**\n\n```objc\nNSArray *foo = @[object, object, object];\n```\n\n**Not:**\n\n```objc\nNSArray *array = [[NSArray alloc] initWithObjects:@\"foo\", @\"bar\", nil];\n\nNSArray *anotherArray = [NSArray arrayWithObjects:@\"foo\", @\"bar\", nil];\n```\n\n## Rule of three\n\n### Protocol Conformation\n\nIf a class conforms to three or more protocols, separate each declaration with line breaks:\n\n**Preferred:** (who doesn't love alphabetizing?)\n\n```objc\n@interface RZViewController : UIViewController\n\u003cRZBeerDelegate,\nRZInfiniteChipotleDelegate,\nRZKitchenDelegate,\nRZLunchFinderDelegate\u003e\n```\n\n\n**Not:**\n\n```objc\n@interface RZViewController : UIViewController \u003cRZKitchenDelegate, RZInfiniteChipotleDelegate, RZLunchFinderDelegate, RZBeerDelegate\u003e\n```\n\n### Method calls/signatures\n\nIf a method has 3 or more parameters, separate the paramters with line breaks:\n\n**Preferred:**\n\n```objc\n- (void)doSomethingWithArray:(NSArray *)array\n                      string:(NSString *)string\n                        bool:(BOOL)bool\n{\n    [super doSomethingWithArray:array\n                         string:string\n                           bool:bool];\n}\n```\n\n**Not:**\n\n```objc\n- (void)doSomethingWithArray:(NSArray *)array string:(NSString *)string bool:(BOOL)bool\n{\n    [super doSomethingWithArray:array string:string number:number bool:bool];\n}\n```\n\nDon't align method calls that take non-`nil` block parameters\n\n```objc\n[super doSomethingWithArray:array string:string bool:bool completion:^{\n    // block code\n}];\n```\n\n## Unnecessary code\n\nAdvances in Clang and Objective-C have made certain conventions obsolete. 99% of the time, we should **no longer use the following**:\n\n- `@synthesize`d properties (except for readonly properties as of Xcode 6)\n- explicitly declared ivars\n- forward declaration of private methods\n    - for readability's sake, private methods should always be grouped under `#pragma mark - Private Methods`\n    - please see the [file organization](#file-organization) page for more on this\n\n## File Organization\n\nObjective-C files should generally be organized in the following order. See the included `RZSampleViewController.h` and `RZSampleViewController.m` to see these rules in practice.\n\n### Header Files (`.h`)\n\n- Framework `@import`s\n- Application header `#import`s (`\"...\"`)\n\n    - These should be used judiciously. Consider forward class declarations and only import in `.m` or `_Private.h` if you can. This can improve build times by reducing the redundancy of header imports.\n- forward `@class` declarations\n- forward `@protocol` declarations\n- `typedef`ed enumerations and block signatures\n- `OBJC_EXTERN`ed constant declarations\n- `@interface` - protocol conformations should be used here judiciously — consider using in `.m` or `_Private.h`; see also [Rule of Three](#rule-of-three))\n\n- **Nothing should be public unless it explicitly needs to be used by other classes**\n\n- `@property` declarations\n    - cluster similar properties into groups separated by a newline\n        - `UIView` subclasses\n        - Other `NSObject` subclasses\n        - `NSLayoutConstraint`s\n        - delegate references\n- class method declarations\n- public interface method declarations\n- `IBOutlet`/`IBAction` should never appear in `.h` files!\n- `@protocol` definitions\n    - `@required` and `@optional` only necessary if both types of methods are present\n\n#### When to use a `_Private.h` file\n\nWhen you have a base class of which you have multiple subclasses. For example:\n\n- Separate iPad and iPhone versions of a class\n- If the subclasses need to inherit private properties and methods\n- You don't want to expose items in the public interface of the base class\n\nWhat to do:\n\n1. Create a new class extension file\n2. Name it YourClass_Private.h\n3. Put all your shared interface elements in that private interface\n4. Import that interface file in your subclasses' implementation files\n\nAn example structure:\n\n- Base Class\n    - `RZMainViewController.m`\n    - `RZMainViewController.h`\n- Private Interface\n    - `RZMainViewController_Private.h`\n- iPhone subclass - .m `#import`s `RZMainViewController_Private.h`\n    - `RZMainViewController~iphone.m`\n    - `RZMainViewController~iphone.h`\n    - `RZMainViewController~iphone.xib`\n- iPad subclass - .m `#import`s `RZMainViewController_Private.h`\n    - `RZMainViewController~ipad.m`\n    - `RZMainViewController~ipad.h`\n    - `RZMainViewController~ipad.xib`\n\n### Implementation Files (`.m`)\n\n- framework `@import`s\n\n- application header imports\n    - cluster different kinds of imports together, with comments if many types are present\n        - view controllers\n        - custom views/cells\n        - data model/managers\n        - categories (always in their own files, never in-line)\n        - constant files\n        - third party software\n- `typedef`ed `enum`s, block signatures\n- macros\n- constant definitions\n- `@interface` extension\n    - Protocol conformations not needed by subclasses. See also: [Rule of Three](#rule-of-three)\n        - See [Header file](#header-files-h) section\n    - `IBAction` method declarations\n        - These are optional, and should be included only for clarity\n    - Not necessary to declare delegate/private methods or property overrides\n- `@implementation`\n    - organize sections with `#pragma mark -`\n    - `@synthesize` statements\n        - only use when necessary, such as with read-only properties\n    - class methods\n    - `init` \u0026 `dealloc`\n    - view lifecycle\n    - notification handlers\n    - delegate callbacks\n    - `IBAction` handlers\n    - overridden property getters/setters\n        - getter and setter for same property should appear consecutively\n    - public interface methods\n    - private interface methods\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frightpoint%2Fraizlabs-cocoa-style","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frightpoint%2Fraizlabs-cocoa-style","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frightpoint%2Fraizlabs-cocoa-style/lists"}