{"id":26879805,"url":"https://github.com/seekingalpha/objectivestyle","last_synced_at":"2026-01-11T05:23:23.315Z","repository":{"id":14845403,"uuid":"17568421","full_name":"seekingalpha/ObjectiveStyle","owner":"seekingalpha","description":"Coding conventions to be followed when programming in Objective-C. An objective way to make a unique style. ObjectiveStyle.","archived":false,"fork":false,"pushed_at":"2016-05-24T09:41:30.000Z","size":19,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":6,"default_branch":"master","last_synced_at":"2024-04-19T11:07:44.382Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/seekingalpha.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-03-09T16:36:43.000Z","updated_at":"2016-05-24T09:40:00.000Z","dependencies_parsed_at":"2022-07-22T09:02:44.137Z","dependency_job_id":null,"html_url":"https://github.com/seekingalpha/ObjectiveStyle","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/seekingalpha%2FObjectiveStyle","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seekingalpha%2FObjectiveStyle/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seekingalpha%2FObjectiveStyle/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seekingalpha%2FObjectiveStyle/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/seekingalpha","download_url":"https://codeload.github.com/seekingalpha/ObjectiveStyle/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246474152,"owners_count":20783434,"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":"2025-03-31T13:32:59.853Z","updated_at":"2026-01-11T05:23:23.276Z","avatar_url":"https://github.com/seekingalpha.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# ObjectiveStyle - The Seeking Alpha Objective-C Style Guide\n\n## Introduction \u0026 Motivation\n\nThe objective of this document is to standardize the code across the iOS team. We grouped here coding conventions so everyone can have the reference to follow available at GitHub.\n\nFeel free to suggest pull requests.\n\n## Table of contents\n\n* [Dot Notation](https://github.com/seekingalpha/ObjectiveStyle#dot-notation)\n* [When using braces...](https://github.com/seekingalpha/ObjectiveStyle#when-using-braces)\n* [Declaring and returning methods](https://github.com/seekingalpha/ObjectiveStyle#declaring-and-returning-methods)\n* [The ternary operator](https://github.com/seekingalpha/ObjectiveStyle#the-ternary-operator)\n* [Objective-C literals](https://github.com/seekingalpha/ObjectiveStyle#objective-c-literals)\n* [Commenting](https://github.com/seekingalpha/ObjectiveStyle#commenting)\n* [Golden path](https://github.com/seekingalpha/ObjectiveStyle#golden-path)\n* [CGGeometry](https://github.com/seekingalpha/ObjectiveStyle#cggeometry)\n* [Typedef Enum](https://github.com/seekingalpha/ObjectiveStyle#Typedef-Enum)\n* [Image naming](https://github.com/seekingalpha/ObjectiveStyle#image-naming)\n* [Singleton creation](https://github.com/seekingalpha/ObjectiveStyle#singleton-creation)\n* [instancetype](https://github.com/seekingalpha/ObjectiveStyle#instancetype)\n* [General considerations](https://github.com/seekingalpha/ObjectiveStyle#general-considerations)\n* [Organization and care](https://github.com/seekingalpha/ObjectiveStyle#organization-and-care)\n* [Le grans finale](https://github.com/seekingalpha/ObjectiveStyle#le-grand-finale)\n\n## Dot notation\n\nDot-notation should **always** be used for accessing and mutating properties. Bracket notation **should not be used** for properties, only for methods.\n\n###Do:\n\n\tview.backgroundColor = [UIColor orangeColor];\n\t[UIApplication sharedApplication].delegate;\n\tNSInteger arrayCount = [myArray count];\n\t\n###Don't:\n\n\t[view setBackgroundColor:[UIColor orangeColor]];\n\tUIApplication.sharedApplication.delegate;\n\tNSInteger arrayCount = myArray.count;\n\t\n## When using braces...\n\nConditional bodies always use braces, even when the conditional body could be written without braces - in one or two lines. This must be done (1) [**to prevent errors**](http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no/16530#16530) and (2) **to be more scannable, more readable**. It’s better to use braces, by security, than having the need to add braces after we discover a bug.\n\n###Do:\n\n\tif (condition) {\n\t    [self justDoIt];\n\t}\n\t\n###Don't:\n\n\tif (condition)\n\t    [self justDoIt];\n\n    if (condition) [self justDoIt];\n\nMoreover, conditional braces should **open in the same line**, and **close in a new line**. Also, before an `if` statement, there should be an **empty line**.\n    \n###Do:\n\n\t[self executeAMethod];\n\t\n\tif (enterTheIf) {\n\t    [self doSomething];\n\t}\n\telse {\n\t    [self doSomethingElse];\n\t}\n\t\n###Don't:\n\n\t[self executeAMethod];\n\t\n\tif (enterTheIf)\n\t{\n\t    [self doSomething];\n\t} else {\n\t    [self doSomethingElse];\n\t}\n\t\nThere is no need to compare results to NO or YES in conditionals.\n    \n###Do:\n\n\tif (user.isCool)\n\n\tif (![user canDoSomething])\t\n\t\n###Don't:\n\n\tif (user.isCool == YES)\n\n\tif ([user canDoSomething] == NO)\n\t\nHowever, **method implementations** should open braces in a **new line**.\n\n###Do:\n\n\t- (void)doSomethingWithText:(NSString *)text image:(UIImage *)image \n\t{\n\t\t//do stuff\n\t}\n\t\n###Don't:\n\n\t- (void)doSomethingWithText:(NSString *)text image:(UIImage *)image {\n\t\t//do stuff\n\t}\n\nWhen methods return an error parameter by reference, the condition should be the returned value of the function, not the error variable. Some of the Apple’s APIs write garbage values to the error parameter even in succesful cases, so switching on the error can cause a false negative, and possibly a crash.\n\n###Do:\n\n\tNSError *error;\n\t\n\tif (![self trySomethingWithError:\u0026error]) {\n\t    // Handle error\n\t}\n\t\n###Don't:\n\n\tNSError *error;\n\t[self trySomethingWithError:\u0026error];\n\t\n\tif (error) {\n\t    // Handle error\n\t}\n\n\n## Declaring and returning methods\n\nIn methods there should be a space after the scope (-/+ symbol), and a space between the kind of parameter and the ‘*’ character. Method names and parameters should start with non-capital case. Methods should be as descriptive as possible: don’t save characters, they are free to use.\n\n###Do:\n\n\t- (void)doSomethingWithText:(NSString *)text image:(UIImage *)image\n\t\n###Don't:\n\n\t-(void)DoSomethingWithText:(NSString*)text Image:(UIImage*)image\n\t\nIn every method that returns a value, keep an empty line before returning the value.\n\nKeep one line between methods to help clarity. Inside a method, one line should separate functionality\n\n###Do:\n\t\n\t-(BOOL)canDoSomething\n\t{\n\t    BOOL shouldDoSomething;\n\t    //calculate what's necessary to get shouldDoSomething and leave an empty line before returning it\n\t    \n\t    return shouldDoSomething;\n\t}\n\t\n## The ternary operator\n\nThe ternary operator, _**?**_, should be used only if it increases code clarity. **Never** use it in a nested way, and avoid using it in situations different than assigning a variable/instance (e.g when defining objects for a collection).\n\n###Do:\n\n\tresult = a \u003e b ? x : y;\n\t\n###Don't:\n\n\tint result = a \u003e b ? x == c + d ? c : d : y;\n\t\n\tNSArray *myArray = @[object1, object2, a \u003e b ? x : y];\n\t\n\n## Objective-C literals\n\nWhen creating instances of NSDictionary, NSArray and NSNumber, prefer [Objective-C Literals](http://www.google.com/url?q=http%3A%2F%2Fblog.bignerdranch.com%2F398-objective-c-literals-part-1%2F\u0026sa=D\u0026sntz=1\u0026usg=AFQjCNFQ4M3SIjWjDHDed0q53aJ9hoMFxQ) instead of foundation methods (and also when accessing objects inside them). For acessing the first object, use the -[NSArray firstObject] method, available in iOS 7+. Please pay attention to the fact that sending nil values into `NSArray` and `NSDictionary` will cause crashes.\n\n###Do:\n\n\tNSNumber *theNumber = @613;\n\tNSArray *theArray = @[@\"Abc\", @\"Def\", @\"Ghi\"];\n\tNSDictionary *theDictionary = @{ @\"Name\" : @\"Natan\", @\"Age\" : @26 };\n\t\nIn case you need a mutable form, you can do it the following way:\n\n###Do:\n\tNSMutableArray *theMutableArray = [@[@\"Abc\", @\"Def\", @\"Ghi\"] mutableCopy];\n\t\nAlso, when accessing your `NSArray`'s and `NSDictionary`'s objects, we recommend you to do it this way:\n\n###Do:\n\tNSString *theString = [theArray firstObject];\n\tNSString *theString = theArray[2];\n\tNSString *theString = theDictionary[@\"Name\"];\n\t\n## Commenting\n\nComments should be used to:\n\n* Explain why a piece of code is important, \n* Warn of possible errors if something is not performed in a specific way\n* Reference where a solution was found from, linking to a blog post or stackoverflow answer.\n* Generate documentation from comments written in header classes.\n\nAll comments used must be kept up-to-date or deleted. Wrong comments lead to errors.\n\nRegarding the comment format:\n\n###Do:\n        // Track the current position point\n        CGFloat originY = CGRectMinY(self.view.frame);\n###Don't:\n        CGFloat originY = CGRectMinY(self.view.frame); // Track the current position point\n        \n##Golden path\nWhen coding with conditionals, the left hand margin of the code should be the \"golden\" or \"happy\" path. That is, don't nest `if` statements. Multiple return statements are OK.\n\n###Do:\n\t- (void)myPreferredMethod\n\t{\n\t\tif (!shouldRunMethod) {\n\t\t\treturn;\n\t\t}\n\t\t\n\t\t//do stuff\n\t}\n\t\n###Don't:\n\t- (void)myPreferredMethod\n\t{\n\t\tif (shouldRunMethod) {\n\t\t\t//do stuff\n\t\t}\n\t}\n\t\n## CGGeometry\nWhen accessing x, y, width or height of a CGRect, always use CGGeometry functions, as recommended by Apple: *“your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics\"*. Prefer this methods instead of manipulating CGRect properties - **they can do some work for you**. For more about CGGeometry, check [NSHipster’s post about it](http://www.google.com/url?q=http%3A%2F%2Fnshipster.com%2Fcggeometry%2F\u0026sa=D\u0026sntz=1\u0026usg=AFQjCNGX-KEjXmBVrbxiw20jUyXv2L3UTA).\n\n###Do:\n\tCGFloat originY = CGRectMinY(self.view.frame);\n\tCGFloat middleY = CGRectMidY(self.view.frame);\n\t\n###Don't:\n\tCGFloat originY = self.view.frame.origin.y;\n\tCGFloat middleY = self.view.frame.origin.y +  self.view.frame.size.heigth/2;\n\n## Typedef Enum\n\nEnumerated types should follow the new type specification, as it has stronger type checking and code completion. \n\n###Do:\n\ttypedef NS_ENUM(NSInteger, SALContentType) {\n\t    SALContentTypeArticle,\n\t    SALContentTypeMarketCurrent,\n\t};\n\n## Image naming\nImages should be named consistently to preserve organization and developer sanity. They should be named as one camel case (without underscores) string with a description of their purpose, followed by the un-prefixed name of the class or property they are customizing (if there is one), followed by a further description of color and/or placement, and finally their state.\n\n###Do:\n\tArticleNavigationButtonWhite@2x.png\n\tArticleNavigationButtonWhiteSelected@2x.png\n\tArticleNavigationButtonBlack@2x.png\n\tArticleNavigationButtonBlackSelected@2x.png\n\n## Singleton creation\n\nSingletons should be created using the [**thread safe pattern**](http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F5720029%2Fcreate-singleton-using-gcds-dispatch-once-in-objective-c\u0026sa=D\u0026sntz=1\u0026usg=AFQjCNHkLOZ52x1bBmy5SY9-QnXdB2JKww) (our [code snippets repository](https://github.com/seekingalpha/CodeSniper) contains [a code snippet of this](https://github.com/seekingalpha/CodeSniper/blob/master/singleton.m)):\n\n###Do:\n\n\t+ (instancetype)sharedInstance\n\t{\n\t    static dispatch_once_t once;\n\t    static id sharedInstance;\n\t    dispatch_once(\u0026once, ^{\n\t        sharedInstance = [[self alloc] init];\n\t    });\n\t    return sharedInstance;\n\t}\n\nThis will [prevent crashes](http://cocoasamurai.blogspot.co.il/2011/04/singletons-your-doing-them-wrong.html).\n\n## instancetype\nInit methods should return instancetype instead of id. This is better for check type in compile time, and also for code autocompletion. To read more about it, [check here](http://www.google.com/url?q=http%3A%2F%2Fnshipster.com%2Finstancetype%2F\u0026sa=D\u0026sntz=1\u0026usg=AFQjCNGPg-LB4R7tQGcAxCHZt-72-cYzUg).\n\n###Do:\n\n\t- (instancetype)initWithText:(NSString *)text;\n\t\n###Don't:\n\n\t- (id)initWithText:(NSString *)text;\n\t\n## General considerations\n\nVariables should be named as descriptively as possible (and single letter variable names should be avoided except, in `for( )` loops). Asterisks indicating pointers belong with the variable, e.g., `NSString \\*text` **not** `NSString\\* text` or `NSString \\* text`. Property definitions should be used in place of naked instance variables **whenever possible**. Direct instance variable access should be avoided except in initializer methods (init, initWithCoder:, etc…), dealloc methods and within custom setters and getters. For more information on using Accessor Methods in Initializer Methods and dealloc, see [here](https://www.google.com/url?q=https%3A%2F%2Fdeveloper.apple.com%2Flibrary%2Fmac%2Fdocumentation%2FCocoa%2FConceptual%2FMemoryMgmt%2FArticles%2FmmPractical.html%23%2F%2Fapple_ref%2Fdoc%2Fuid%2FTP40004447-SW6\u0026sa=D\u0026sntz=1\u0026usg=AFQjCNHrj-h-GQ709HPjtcdvjx-5XZcU0Q \"Use Accessor Methods to Make Memory Management Easier\").\n\n###Do:\n\n\t@interface SALObject : NSObject\n\t\n\t@property (nonatomic) NSString *someText;\n\t\n\t@end\n\t\n###Don't:\n\n\t@interface SALObject : NSObject {\n\t    NSString *someText;\n\t}\n\t\nUnderscores should be used **only** when synthesizing a property and calling the backing instance (i.e. _variableName). **As LLVM can synthesize variables automatically, let it do this work for you.**\n\nNames of objects should be as descriptive as possible, and should never abbreviate words. Again, don’t save characters, they are free.\n\n###Do:\n\n\tUIButoon *settingsButton;\n\t\n###Don't:\n\n\tUIButoon *setBut;\n\t\nA three letter prefix should always be used for class names and constants (only not for Core Data entities). Constants should be camel-case with all words capitalized, and prefixed by the related class name for clarity. Also, constants should be declared as static and not #define unless it’s a macro.\n\n###Do:\n\n\tstatic const NSTimeInterval SALPostViewControllerFadeAnimationDuration = 0.25;\n\tstatic NSString * const SALAbouViewControllerCompanyName = @\"Seeking Alpha\";\n\t\n###Don't:\n\n\tstatic conts NSTimeInterval fadetime = 0.25;\n\t#define CompanyName @\"Seeking Alpha\"\n\t\n`dealloc` methods should be placed at the top of the implementation, directly after `@synthesize` and `@dynamic`. `init` should be placed directly below `dealloc`.\n\nIf the name of a `BOOL` property is an adjective, the property should omit the “is\" prefix, but should specify the conventional name for the get accessor.\n\n\t@property (assign, getter=isCool) BOOL pro;\n\nIndentation should be done with cmd+[ and cmd-] so it is done via Xcode (setting on the preferences, and not with tabs.\n\n##Organization and care\n\nDon’t try to write too much code in one line only. In the same way, don’t break your code too much so that you will need 10 lines to do something you could use 5. \n\nMethods with up to 3, 4 arguments, write in only one line when calling them. If it has more than that, break one line for each argument. It means, if calling a method will take more than one line, you should split it into the number of arguments. Otherwise, keep it in one line.\n\nUse `#pragma mark -` to organize methods in functional groupings. Insert a blank line before and after it for better readability. \n\nUS English should be used and developers should care to write code with correctly spelled english.\n\n#Le grand finale\n\nAs a rule of thumb, when you come across with some situation that is not described here, think about the most sensible and wise way to deal with. Or better than that - ask you iOS mates. They will deal with this code another day.\n\n**Thou shall not ignore the rules of this style guide!**\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fseekingalpha%2Fobjectivestyle","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fseekingalpha%2Fobjectivestyle","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fseekingalpha%2Fobjectivestyle/lists"}