{"id":3297,"url":"https://github.com/github/objective-c-style-guide","last_synced_at":"2025-09-28T23:32:29.820Z","repository":{"id":4814974,"uuid":"5968664","full_name":"github/objective-c-style-guide","owner":"github","description":"**Archived** Style guide \u0026 coding conventions for Objective-C projects","archived":true,"fork":false,"pushed_at":"2017-11-08T16:07:32.000Z","size":47,"stargazers_count":1676,"open_issues_count":3,"forks_count":248,"subscribers_count":384,"default_branch":"master","last_synced_at":"2024-09-27T04:01:59.613Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"huangz1990/real-world-haskell-cn","license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/github.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":"2012-09-26T16:21:16.000Z","updated_at":"2024-09-22T08:45:08.000Z","dependencies_parsed_at":"2022-09-05T08:30:24.445Z","dependency_job_id":null,"html_url":"https://github.com/github/objective-c-style-guide","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/github%2Fobjective-c-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/github%2Fobjective-c-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/github%2Fobjective-c-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/github%2Fobjective-c-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/github","download_url":"https://codeload.github.com/github/objective-c-style-guide/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":234575214,"owners_count":18854924,"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-01-05T20:16:37.417Z","updated_at":"2025-09-28T23:32:24.575Z","avatar_url":"https://github.com/github.png","language":null,"readme":"# This repository is no longer active.\n\n-----\n\nThese guidelines build on Apple's existing [Coding Guidelines for Cocoa](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html).\nUnless explicitly contradicted below, assume that all of Apple's guidelines apply as well.\n\n## Whitespace\n\n * Tabs, not spaces.\n * End files with a newline.\n * Make liberal use of vertical whitespace to divide code into logical chunks.\n * Don’t leave trailing whitespace.\n    * Not even leading indentation on blank lines.\n\n## Documentation and Organization\n\n * All method declarations should be documented.\n * Comments should be hard-wrapped at 80 characters.\n * Comments should be [Tomdoc](http://tomdoc.org/)-style.\n * Document whether object parameters allow `nil` as a value.\n * Use `#pragma mark`s to categorize methods into functional groupings and protocol implementations, following this general structure:\n\n```objc\n#pragma mark Properties\n\n@dynamic someProperty;\n\n- (void)setCustomProperty:(id)value {}\n\n#pragma mark Lifecycle\n\n+ (instancetype)objectWithThing:(id)thing {}\n- (instancetype)init {}\n\n#pragma mark Drawing\n\n- (void)drawRect:(CGRect) {}\n\n#pragma mark Another functional grouping\n\n#pragma mark GHSuperclass\n\n- (void)someOverriddenMethod {}\n\n#pragma mark NSCopying\n\n- (id)copyWithZone:(NSZone *)zone {}\n\n#pragma mark NSObject\n\n- (NSString *)description {}\n```\n\n## Declarations\n\n * Never declare an ivar unless you need to change its type from its declared property.\n * Don’t use line breaks in method declarations.\n * Prefer exposing an immutable type for a property if it being mutable is an implementation detail. This is a valid reason to declare an ivar for a property.\n * Always declare memory-management semantics even on `readonly` properties.\n * Declare properties `readonly` if they are only set once in `-init`.\n * Don't use `@synthesize` unless the compiler requires it. Note that optional properties in protocols must be explicitly synthesized in order to exist.\n * Declare properties `copy` if they return immutable objects and aren't ever mutated in the implementation. `strong` should only be used when exposing a mutable object, or an object that does not conform to `\u003cNSCopying\u003e`.\n * Avoid `weak` properties whenever possible. A long-lived weak reference is usually a code smell that should be refactored out.\n * Instance variables should be prefixed with an underscore (just like when implicitly synthesized).\n * Don't put a space between an object type and the protocol it conforms to.\n\n```objc\n@property (attributes) id\u003cProtocol\u003e object;\n@property (nonatomic, strong) NSObject\u003cProtocol\u003e *object;\n```\n\n * C function declarations should have no space before the opening parenthesis, and should be namespaced just like a class.\n\n```objc\nvoid GHAwesomeFunction(BOOL hasSomeArgs);\n```\n\n * Constructors should generally return [`instancetype`](http://clang.llvm.org/docs/LanguageExtensions.html#related-result-types) rather than `id`.\n * Prefer helper functions (such as `CGRectMake()`) to C99 struct initialiser syntax.\n\n```objc\n  CGRect rect = CGRectMake(3.0, 12.0, 15.0, 80.0);\n   ```\n\n## Expressions\n\n * Don't access an ivar unless you're in `-init`, `-dealloc` or a custom accessor.\n * Use dot-syntax when invoking idempotent methods, including setters and class methods (like `NSFileManager.defaultManager`).\n * Use object literals, boxed expressions, and subscripting over the older, grosser alternatives.\n * Comparisons should be explicit for everything except `BOOL`s.\n * Prefer positive comparisons to negative.\n * Long form ternary operators should be wrapped in parentheses and only used for assignment and arguments.\n\n```objc\nBlah *a = (stuff == thing ? foo : bar);\n```\n\n* Short form, `nil` coalescing ternary operators should avoid parentheses.\n\n```objc\nBlah *b = thingThatCouldBeNil ?: defaultValue;\n```\n\n * Separate binary operands with a single space, but unary operands and casts with none:\n\n```c\nvoid *ptr = \u0026value + 10 * 3;\nNewType a = (NewType)b;\n\nfor (int i = 0; i \u003c 10; i++) {\n    doCoolThings();\n}\n```\n\n## Control Structures\n\n * Always surround `if` bodies with curly braces if there is an `else`. Single-line `if` bodies without an `else` should be on the same line as the `if`.\n * All curly braces should begin on the same line as their associated statement. They should end on a new line.\n * Put a single space after keywords and before their parentheses.\n * Return and break early.\n * No spaces between parentheses and their contents.\n\n```objc\nif (somethingIsBad) return;\n\nif (something == nil) {\n\t// do stuff\n} else {\n\t// do other stuff\n}\n```\n\n## Exceptions and Error Handling\n\n * Don't use exceptions for flow control.\n * Use exceptions only to indicate programmer error.\n * To indicate errors, use an `NSError **` argument or send an error on a [ReactiveCocoa](https://github.com/ReactiveCocoa/ReactiveCocoa) signal.\n\n## Blocks\n\n * Blocks should have a space between their return type and name.\n * Block definitions should omit their return type when possible.\n * Block definitions should omit their arguments if they are `void`.\n * Parameters in block types should be named unless the block is initialized immediately.\n\n```objc\nvoid (^blockName1)(void) = ^{\n    // do some things\n};\n\nid (^blockName2)(id) = ^ id (id args) {\n    // do some things\n};\n```\n\n## Literals\n\n * Avoid making numbers a specific type unless necessary (for example, prefer `5` to `5.0`, and `5.3` to `5.3f`).\n * The contents of array and dictionary literals should have a space on both sides.\n * Dictionary literals should have no space between the key and the colon, and a single space between colon and value.\n\n``` objc\nNSArray *theStuff = @[ @1, @2, @3 ];\n\nNSDictionary *keyedStuff = @{ GHDidCreateStyleGuide: @YES };\n```\n\n * Longer or more complex literals should be split over multiple lines (optionally with a terminating comma):\n\n``` objc\nNSArray *theStuff = @[\n    @\"Got some long string objects in here.\",\n    [AndSomeModelObjects too],\n    @\"Moar strings.\"\n];\n\nNSDictionary *keyedStuff = @{\n    @\"this.key\": @\"corresponds to this value\",\n    @\"otherKey\": @\"remoteData.payload\",\n    @\"some\": @\"more\",\n    @\"JSON\": @\"keys\",\n    @\"and\": @\"stuff\",\n};\n```\n\n## Categories\n\n * Categories should be named for the sort of functionality they provide. Don't create umbrella categories.\n * Category methods should always be prefixed.\n * If you need to expose private methods for subclasses or unit testing, create a class extension named `Class+Private`.\n","funding_links":[],"categories":["Style Guides","Objective-C","Unofficial","WebSocket","Programming Languages","Others","非官方"],"sub_categories":["Keychain","Vue","Other Xcode","Other free courses","Objective-C","\u003ca name=\"other-xcode\"\u003e\u003c/a\u003e其他 Xcode 插件","Misc"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgithub%2Fobjective-c-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgithub%2Fobjective-c-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgithub%2Fobjective-c-style-guide/lists"}