{"id":17069002,"url":"https://github.com/kgn/codingconventions","last_synced_at":"2026-04-09T09:40:59.383Z","repository":{"id":10054369,"uuid":"12103643","full_name":"kgn/CodingConventions","owner":"kgn","description":"Name \u0026 Code Conventions for 1kLabs, Inc.","archived":false,"fork":false,"pushed_at":"2013-09-18T06:26:08.000Z","size":188,"stargazers_count":2,"open_issues_count":2,"forks_count":0,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-01-28T17:15:46.305Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://playsesame.com","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/kgn.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":"2013-08-14T08:16:06.000Z","updated_at":"2016-10-19T05:44:50.000Z","dependencies_parsed_at":"2022-09-06T02:51:02.078Z","dependency_job_id":null,"html_url":"https://github.com/kgn/CodingConventions","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/kgn%2FCodingConventions","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kgn%2FCodingConventions/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kgn%2FCodingConventions/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kgn%2FCodingConventions/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kgn","download_url":"https://codeload.github.com/kgn/CodingConventions/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245090894,"owners_count":20559296,"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-10-14T11:15:52.563Z","updated_at":"2025-12-30T23:34:40.282Z","avatar_url":"https://github.com/kgn.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"Main items like repo names, folders, and classes are in [PascalCase](http://c2.com/cgi/wiki?PascalCase).\n\nLesser items like class properties and variables are in [camelCase](http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx).\n\nThe namespace is `OKL`, used for all Cocoa, Python, and JavaScript/CoffeeScript global objects.\n\nIt's very easy in code to be overly clever, don't be. Make the code readable and understandable by others and your future self. This includes things like separating complex code into multiple lines with comments, and clear variable names, even if they get really long. Take 5 extra seconds now when writing the code to avoid loosing 5 minutes later when reading it.\n\nThis is a living document so please make suggestions and refer back to it for changes.\n\n# Git\n\n## Repos\n\nGet repositories are pascal-case and namespaced with the project name.\n\n**For example:**\n\n```\nSesameCocoa\nSesameWebsite\n```\n\n## Branches\n\nGit branches are grouped together by the `/` separator so they are organized into *directories* in GUI apps.\n\nThere are currently two groups:\n- `feature` - A feature branch. Examples: `feature/sound-control`, `feature/x-ray`\n- `build` - A build branch for the build system. Examples: `build/release`, `build/beta`.\n\n# Python\n\nPython naming conventions follow what's outlined above. Pascal-case for modules and classes, and camel-case for variable names.\n\n## Quotes\n\nSingle quotes should be used, unless there are single quotes in the string then double quotes maybe used. Avoid escaping quotes.\n\n**For example:**\n\n```python\nwhereTitle = 'Know where this is?'\nwhosTitle \"Know who's in this photo?\"\n```\n\n## Classes\n\nClasses should begin with the three letter `OKL` namespace.\nClasses should always inherit from `object`.\n\n**For example:**\n\n```python\nclass OKLPhoto(object):\n    def __init__(self, objectId):\n        self.objectId = objectId\n```\n\n## Package Structure\n\nModules should use `__all__` to expose a clean public API for the module. \n`__init__.py` should not contain code but should only perform imports from other \nmodules to create a clean API for the package.\n\n**For example:**\n\n`Object.py`\n```python\n__all__ = ('OKLPhoto', 'OKLUser')\n```\n\n`__init__.py`\n```python\nfrom Photo import OKLPhoto\nfrom Server import *\n```\n\n# C Based Syntax Languages\n\n## Spacing\n\n* 4 spaces, not tabs.\n* Files should always end with a new line.\n* No more than three newlines should be used to divide code, any more is just silly. There are better ways to do so like comments and pragma marks.\n* Additional space should not be added between variable type, names, and value to make them line up. If you like you came order the lines from shortest to longest.\n* Code should be concise and compact. Avoid adding spaces between brackets, parentheses, and braces.\n\n**For example:**\n```objc\nint x = 10;\nint width = 300;\n```\n\n**Not:**\n```objc\nint     x  =   10;\nint width  =  300;\n```\n\n\n\n## Braces\n\nMethod braces and other braces (`if`/`else`/`switch`/`while` etc.) always open on the same line as the statement but close on a new line.\nThere should be no space around the braces to make the code more compact.\n\n**For example:**\n```objc\nif(user.isHappy){\n    //Do something\n}else{\n    //Do something else\n}\n```\n\n## Conditionals\n\nConditional bodies should always use braces even when a conditional body could be written without braces (e.g., it is one line only) to prevent [errors](https://github.com/NYTimes/objective-c-style-guide/issues/26#issuecomment-22074256). These errors include adding a second line and expecting it to be part of the if-statement. Another, [even more dangerous defect](http://programmers.stackexchange.com/a/16530) may happen where the line \"inside\" the if-statement is commented out, and the next line unwittingly becomes part of the if-statement. In addition, this style is more consistent with all other conditionals, and therefore more easily scannable.\n\n**For example:**\n```objc\nif(!error){\n    return success;\n}\n```\n\n**Not:**\n```objc\nif (!error)\n    return success;\n```\n\nor\n\n```objc\nif (!error) return success;\n```\n\n### Ternary Operator\n\nThe Ternary operator, ? , should only be used when it increases clarity or code neatness. A single condition is usually all that should be evaluated. Evaluating multiple conditions is usually more understandable as an if statement, or refactored into instance variables.\n\n**For example:**\n```objc\nresult = a \u003e b ? x : y;\n```\n\n**Not:**\n```objc\nresult = a \u003e b ? x = c \u003e d ? c : d : y;\n```\n\n## Comments\n\nComments should be used sparingly due to the self documenting nature of Objective-C.\nComments should be used to explain **why** a particular piece of code does something. \nAny comments that are used must be kept up-to-date or deleted.\n\nThere should always be a space after the `//`.\n\n**For example:**\n```objc\n// This is where we do the thing\n```\n\nBlock comments should generally be avoided, as code should be as self-documenting as possible, \nwith only the need for intermittent, few-line explanations. \nThis does not apply to comments that are used to generate documentation.\n\n### TODO\n\nThe `// TODO:` comment is encuraged to make notes of what is needed to be done. \nAs soon as a todo is complete the comment should be deleted.\n\n**For example:**\n```objc\n// TODO: Still have to add threading\n```\n\n### HACK\n\nThe `// HACK:` comment should be used to flag a particually hacky peice of code that is working but should probaly be fixed in the future.\n\n**For example:**\n```objc\n// HACK: Not sure why 5px needs to be added here but it's working\n```\n\n# Objective-C\n\n## Types\n\n`NSInteger` and `NSUInteger` should be used instead of `int`, `long`, etc per Apple's best practices and 64-bit safety. `CGFloat` is preferred over `float` for the same reasons. This future proofs code for 64-bit platforms.\n\nAll Apple types should be used over primitive ones. For example, if you are working with time intervals, use `NSTimeInterval` instead of `double` even though it is synonymous. This is considered best practice and makes for clearer code.\n\n## Dot Notation\n\nAvoid mixing square brackets and dots.\n\n**For example:**\n```objc\n[[UIApplication sharedApplication] delegate];\n```\nor\n```\nUIApplication *app = [UIApplication sharedApplication];\napp.delegate;\n```\n\n**Not:**\n```objc\n[UIApplication sharedApplication].delegate;\n```\nor\n```\nUIApplication.sharedApplication.delegate;\n```\n\n## Variables\n\nVariables should be named as descriptively as possible. Single letter variable names should be avoided except in `for()` loops.\n\nAsterisks indicating pointers belong with the variable, e.g., `NSString *text` not `NSString* text` or `NSString * text`, except in the case of constants.\n\nProperty 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://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW6).\n\n**For example:**\n\n```objc\n@interface OKLUser: NSObject\n\n@property (strong, nonatomic) NSString *name;\n\n@end\n```\n\n**Not:**\n\n```objc\n@interface OKLUser : NSObject {\n    NSString *name;\n}\n```\n\n## Properties\n\n```objective-c\n@property (strong, nonatomic) UIColor *topColor;\n@property (nonatomic) CGSize shadowOffset;\n@property (weak, nonatomic, readonly) UIActivityIndicatorView *activityIndicator;\n@property (nonatomic, getter=isLoading) BOOL loading;\n```\n\nIf the property is `strong` or `weak`, it should be first. The next option should `nonatomic` if it is specified. `readonly` should be the next option if it is specified. `readwrite` should never be specified in header file. `readwrite` should only be used in class extensions. `getter` or `setter` should be last. `setter` should rarely be used.\n\nAny object that is inherently owned by another object should be defined as `weak`. Delegates and views are examples of these types of objects. Views should be defined as `weak` because they are retained by their super view.\n\n## Methods\n\nIn method signatures, there should be a space after the scope (-/+ symbol). There should be a space between the method segments.\n\n**For Example**:\n```objc\n- (void)setExampleText:(NSString *)text image:(UIImage *)image;\n```\n\n## Pragma Mark and Implementation Organization\n\nPragma marks should be used to better organize code. They should be used to group section of code into logical chunks.\n\nPragma marks should **always** be used to denote delegate methods.\n\n**For example:**\n\n```objc\n#pragma mark - UITableViewDelegate\n\n// table view delegate methods\n\n#pragma mark - UITableViewDataSource\n\n// table view data source methods\n\n```\n\n## Naming\n\nApple naming conventions should be adhered to wherever possible, especially those related to [memory management rules](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html) ([NARC](http://stackoverflow.com/a/2865194/340508)).\n\nLong, descriptive method and variable names are good.\n\n**For example:**\n\n```objc\nUIButton *settingsButton;\n```\n\n**Not**\n\n```objc\nUIButton *setBut;\n```\n\nA three letter prefix (e.g. `OKL`) should always be used for class names and constants. \nConstants should be camel-case with all words capitalized and prefixed by the related class name for clarity.\n\n**For example:**\n\n```objc\nstatic const NSTimeInterval OKLPhotoViewControllerFadeAnimationDuration = 0.3;\n```\n\n**Not:**\n\n```objc\nstatic const NSTimeInterval fadetime = 1.7;\n```\n\nProperties should be camel-case with the leading word being lowercase. \n**If Xcode can automatically synthesize the variable, then let it.** \nOtherwise, in order to be consistent, the backing instance variables for these properties should be camel-case with the leading word being lowercase and a leading underscore. \nThis is the same format as Xcode's default synthesis.\n\n**For example:**\n\n```objc\n@synthesize descriptiveVariableName = _descriptiveVariableName;\n```\n\nUIControl properties should begin with a descriptive name and end with the name of the control.\n\n**For example:**\n\n```objc\n@property (weak, nonatomic) UIView *profileView;\n@property (weak, nonatomic) UILabel *usernameLabel;\n@property (weak, nonatomic) UIImageView *photoImageView;\n```\n\n### Underscores\n\nWhen using properties, instance variables should always be accessed and mutated using `self.`. \nThis means that all properties will be visually distinct, as they will all be prefaced with `self.`. \nLocal variables should not contain underscores.\n\n## Import\n\n**Always** use `@class` whenever possible in header files instead of `#import` since it has a slight compile time performance boost.\n\nFrom the [Objective-C Programming Guide](http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf) (Page 38):\n\n\u003e The @class directive minimizes the amount of code seen by the compiler and linker, and is therefore the simplest way to give a forward declaration of a class name. Being simple, it avoids potential problems that may come with importing files that import still other files. For example, if one class declares a statically typed instance variable of another class, and their two interface files import each other, neither class may compile correctly.\n\n### Header Prefix\n\nAdding frameworks that are used in the majority of a project to a header prefix is preferred. If these frameworks are in the header prefix, they should **never** be imported in source files in the project.\n\nFor example, if a header prefix looks like the following:\n\n```objective-c\n#ifdef __OBJC__\n    #import \u003cFoundation/Foundation.h\u003e\n    #import \u003cUIKit/UIKit.h\u003e\n#endif\n```\n\n`#import \u003cFoundation/Foundation.h\u003e` should never occur in the project outside of the header prefix.\n\n## init and dealloc\n\n`dealloc` methods should be placed at the top of the implementation, \ndirectly after the `@synthesize` and `@dynamic` statements. \n`init` should be placed directly below the `dealloc` methods of any class.\n\n`instancetype` should always be used for `init` and class methods that return the initialized object.\n\n`init` methods should be structured like this:\n\n```objc\n- (instancetype)init{\n    self = [super init];\n    if(self){\n        // Custom initialization\n    }\n    return self;\n}\n```\n\nHelper class methods are preferred for creating custom object.\n\n**For example:**\n\n```objc\n+ (instancetype)photoViewControllerWithPhoto:(OKLPhoto *)photo andDelegate:(id\u003cOKLPhotoViewControllerDelegate\u003e)delegate;\n```\n\n## Literals\n\n`NSString`, `NSDictionary`, `NSArray`, and `NSNumber` literals should be used whenever creating immutable instances of those objects. \nPay special care that `nil` values not be passed into `NSArray` and `NSDictionary` literals, as this will cause a crash.\nThe prefered method of dealing with this potential is `@{@\"data\": object ?: [NSNull null]}`.\n\n**For example:**\n\n```objc\nNSArray *names = @[@\"Brian\", @\"Matt\", @\"Chris\", @\"Alex\", @\"Steve\", @\"Paul\"];\nNSDictionary *productManagers = @{@\"iPhone\": @\"Kate\", @\"iPad\": @\"Kamal\", @\"Mobile Web\": @\"Bill\"};\nNSNumber *shouldUseLiterals = @YES;\nNSNumber *buildingZIPCode = @10018;\n```\n\n**Not:**\n\n```objc\nNSArray *names = [NSArray arrayWithObjects:@\"Brian\", @\"Matt\", @\"Chris\", @\"Alex\", @\"Steve\", @\"Paul\", nil];\nNSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @\"Kate\", @\"iPhone\", @\"Kamal\", @\"iPad\", @\"Bill\", @\"Mobile Web\", nil];\nNSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];\nNSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018];\n```\n\n## Extern, Const, and Static\n\n```objective-c\nextern NSString *const kMyConstant;\nextern NSString *MyExternString;\nstatic NSString *const kMyStaticConstant;\nstatic NSString *staticString;\n```\n\n## Auto Layout\n\nAuto layout should be used for all views. Use [Richard Turton's `UIView+AutoLayout`](https://github.com/jrturton/UIView-Autolayout) to define the constraints.\nMore information can be found out about these category methods and auto layout in [this blog post](http://commandshift.co.uk/blog/2013/02/20/creating-individual-layout-constraints/).\n\n## CGRect\n\n### Make\n\nCreating a `CGRect` often results in a very long line of code. For this reason it is preferred to manipulate a rectangle over multiple lines rather than on long `CGRectMake` line.\n\n**For example:**\n```objc\nCGRect frame = CGRectZero;\nframe.size = image.size;\nframe.origin.y = CGRectGetMaxY(label.frame);\nframe.origin.x = round(CGRectGetMidX(self.view.bounds)-CGrectGetMidX(frame));\n```\n\n**Not:**\n\n```objc\nCGRect frame = CGRectMake(round(CGRectGetMidX(self.view.bounds)-image.size.width/2), CGRectGetMaxY(label.frame), image.size.width, image.size.height);\n```\n\n### Functions\n\nWhen accessing the `x`, `y`, `width`, or `height` of a `CGRect`, always use the [`CGGeometry` functions](http://developer.apple.com/library/ios/#documentation/graphicsimaging/reference/CGGeometry/Reference/reference.html) instead of direct struct member access. From Apple's `CGGeometry` reference:\n\n\u003e All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, 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.\n\n**For example:**\n\n```objc\nCGRect frame = self.view.frame;\n\nCGFloat x = CGRectGetMinX(frame);\nCGFloat y = CGRectGetMinY(frame);\nCGFloat width = CGRectGetWidth(frame);\nCGFloat height = CGRectGetHeight(frame);\n```\n\n**Not:**\n\n```objc\nCGRect frame = self.view.frame;\n\nCGFloat x = frame.origin.x;\nCGFloat y = frame.origin.y;\nCGFloat width = frame.size.width;\nCGFloat height = frame.size.height;\n```\n\n## Constants\n\nConstants are preferred over in-line string literals or numbers, as they allow for easy reproduction of commonly used variables and can be quickly changed without the need for find and replace. Constants should be declared as `static` constants and not `#define`s unless explicitly being used as a macro.\n\nIf you find yourself writing `#define` stop and ask yourself, is this really the best way to do this… most often there is.\n\n**For example:**\n\n```objc\nstatic NSString *const OKLAboutViewControllerCompanyName = @\"1kLabs, Inc.\";\n\nstatic const CGFloat OKLImageThumbnailHeight = 50.0;\n```\n\n**Not:**\n\n```objc\n#define CompanyName @\"1kLabs, Inc.\"\n\n#define thumbnailHeight 2\n```\n\n## Enumerated Types\n\nWhen using `enum`s, it is recommended to use the new fixed underlying type specification because it has stronger type checking and code completion. \nThe SDK now includes a macro to facilitate and encourage use of fixed underlying types — `NS_ENUM()`\n\n`enum` names should be prefixed with the base name followed by the specific name.\n\n**Example:**\n\n```objc\ntypedef NS_ENUM(NSInteger, OKLPhotoType){\n    OKLPhotoTypeWho,\n    OKLPhotoTypeWhat,\n    OKLPhotoTypeWhere\n};\n```\n\n## Private Properties\n\nPrivate properties should be declared in class extensions (anonymous categories) in a separate header file for the class: `OKLPhoto+Private.h`. \nThis way other classes in the API can use the private properties and methods but the interface will be clean to the end user of the API.\nNamed categories (such as `OKLPrivate` or `private`) should never be used unless extending another class.\n\n**For example:**\n\n```objc\n@interface OKLPhoto()\n\n@property (strong, nonatomic) OKLUser *user;\n@property (nonatomic) OKLPhotoType photoType;\n@property (nonatomic) NSInteger guessCount;\n\n@end\n```\n\n## Image Naming\n\nImage names should be named consistently to preserve organization and developer sanity. \nThey should be named as one pascal-case string with a description of their purpose, \nfollowed by the un-prefixed name of the class or property they are customizing (if there is one), \nfollowed by a further description of color and/or placement, and finally their state.\n\n**For example:**\n\n* `RefreshBarButtonItem` / `RefreshBarButtonItem@2x` and `RefreshBarButtonItemSelected` / `RefreshBarButtonItemSelected@2x`\n* `ArticleNavigationBarWhite` / `ArticleNavigationBarWhite@2x` and `ArticleNavigationBarBlackSelected` / `ArticleNavigationBarBlackSelected@2x`.\n\n## Booleans\n\nSince `nil` resolves to `NO` it is unnecessary to compare it in conditions. Never compare something directly to `YES`, because `YES` is defined to 1 and a `BOOL` can be up to 8 bits.\n\nThis allows for more consistency across files and greater visual clarity.\n\n**For example:**\n\n```objc\nif(!someObject){\n}\n```\n\n**Not:**\n\n```objc\nif(someObject == nil){\n}\n```\n\n-----\n\n**For a `BOOL`, here are two examples:**\n\n```objc\nif(isAwesome)\nif(![someObject boolValue])\n```\n\n**Not:**\n\n```objc\nif([someObject boolValue] == NO)\nif(isAwesome == YES) // Never do this.\n```\n\n-----\n\nDeriving truth value directly from an arithmetic operation is never a good idea. \nInstead, use the result of the == operator, or cast values into booleans with the ! (or !!) operator.\n\n**For example:**\n\n```objc\nNSInteger age = 12;\nif(!!age){\n    // age is not 0\n}\n```\n\nor\n\n```objc\nNSInteger age = 12;\nif(age != 0){\n    // age is not 0\n}\n```\n\nFrom [NSHipster BOOL](http://nshipster.com/bool) post.\n\n-----\n\nIf the name of a `BOOL` property is expressed as an adjective, the property can omit the “is” prefix but specifies the conventional name for the get accessor, for example:\n\n```objc\n@property (getter=isEditable) BOOL editable;\n```\nText and example taken from the [Cocoa Naming Guidelines](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE).\n\n## Singletons\n\nSingleton objects should use a thread-safe pattern for creating their shared instance.\n\n```objc\n+ (instancetype)sharedInstance{\n   static id sharedInstance = nil;\n   static dispatch_once_t onceToken;\n   dispatch_once(\u0026onceToken, ^{\n      sharedInstance = [[self alloc] init];\n   });\n   return sharedInstance;\n}\n```\n\nThis will prevent [possible and sometimes prolific crashes](http://cocoasamurai.blogspot.com/2011/04/singletons-your-doing-them-wrong.html).\n\n# References\n\nMany of the Objective-C guides are from the [New York Times: Objective-C Style Guide](https://github.com/NYTimes/objective-c-style-guide) \u0026 [Sam Soffes: Objective-C Coding Convention and Best Practices](https://gist.github.com/soffes/812796), much of the text is straight up copied because they did such a great job with it!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkgn%2Fcodingconventions","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkgn%2Fcodingconventions","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkgn%2Fcodingconventions/lists"}