└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Button Objective-C Style Guide 2 | 3 | This style guide outlines the coding conventions of the iOS team at Button. It was forked from the [NYT style guide](https://github.com/NYTimes/objective-c-style-guide). 4 | 5 | ## Introduction 6 | 7 | Here are some of the documents from Apple that informed the style guide. If something isn’t mentioned here, it’s probably covered in great detail in one of these: 8 | 9 | * [The Objective-C Programming Language](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html) 10 | * [Cocoa Fundamentals Guide](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/Introduction.html) 11 | * [Coding Guidelines for Cocoa](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html) 12 | * [iOS App Programming Guide](http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/Introduction/Introduction.html) 13 | 14 | This style guide conforms to IETF's [RFC 2119](http://tools.ietf.org/html/rfc2119). In particular, code which goes against the RECOMMENDED/SHOULD style is allowed, but should be carefully considered. 15 | 16 | ## Table of Contents 17 | 18 | * [Dot Notation Syntax](#dot-notation-syntax) 19 | * [Spacing](#spacing) 20 | * [Conditionals](#conditionals) 21 | * [Ternary Operator](#ternary-operator) 22 | * [Error handling](#error-handling) 23 | * [Methods](#methods) 24 | * [Variables](#variables) 25 | * [Generics](#generics) 26 | * [Naming](#naming) 27 | * [Categories](#categories) 28 | * [Comments](#comments) 29 | * [Init & Dealloc](#init-and-dealloc) 30 | * [Literals](#literals) 31 | * [CGRect Functions](#cgrect-functions) 32 | * [Constants](#constants) 33 | * [Enumerated Types](#enumerated-types) 34 | * [Bitmasks](#bitmasks) 35 | * [Private Properties](#private-properties) 36 | * [Image Naming](#image-naming) 37 | * [Booleans](#booleans) 38 | * [Singletons](#singletons) 39 | * [Imports](#imports) 40 | * [Protocols](#protocols) 41 | * [Xcode Project](#xcode-project) 42 | 43 | ## Dot Notation Syntax 44 | 45 | Dot notation is RECOMMENDED over bracket notation for getting and setting properties. 46 | 47 | **For example:** 48 | ```objc 49 | view.backgroundColor = [UIColor orangeColor]; 50 | [UIApplication sharedApplication].delegate; 51 | ``` 52 | 53 | **Not:** 54 | ```objc 55 | [view setBackgroundColor:[UIColor orangeColor]]; 56 | UIApplication.sharedApplication.delegate; 57 | ``` 58 | 59 | ## Spacing 60 | 61 | * Indentation MUST use 4 spaces. Never indent with tabs. Be sure to set this preference in Xcode. 62 | * Method braces and other braces (`if`/`else`/`switch`/`while` etc.) MUST open on the same line as the statement. Braces MUST close on a new line. 63 | 64 | **For example:** 65 | ```objc 66 | if (user.isHappy) { 67 | // Do something 68 | } 69 | else { 70 | // Do something else 71 | } 72 | ``` 73 | 74 | * There SHOULD be exactly two blank lines between methods to aid in visual clarity and organization. 75 | * Whitespace within methods MAY separate functionality, though this inclination often indicates an opportunity to split the method into several, smaller methods. In methods with long or verbose names, a single line of whitespace MAY be used to provide visual separation before the method’s body. 76 | * `@synthesize` and `@dynamic` MUST each be declared on new lines in the implementation. 77 | 78 | ## Conditionals 79 | 80 | Conditional bodies MUST 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) can 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. 81 | 82 | **For example:** 83 | ```objc 84 | if (!error) { 85 | return success; 86 | } 87 | ``` 88 | 89 | **Not:** 90 | ```objc 91 | if (!error) 92 | return success; 93 | ``` 94 | 95 | or 96 | 97 | ```objc 98 | if (!error) return success; 99 | ``` 100 | 101 | ### Ternary Operator 102 | 103 | The intent of the ternary operator, `?` , is to increase clarity or code neatness. The ternary SHOULD only evaluate a single condition per expression. Evaluating multiple conditions is usually more understandable as an if statement or refactored into named variables. 104 | 105 | **For example:** 106 | ```objc 107 | result = a > b ? x : y; 108 | ``` 109 | 110 | **Not:** 111 | ```objc 112 | result = a > b ? x = c > d ? c : d : y; 113 | ``` 114 | 115 | Where applicable, the self-coalescing ternary operator SHOULD be used. 116 | 117 | **For example:** 118 | ```objc 119 | result = a ?: b 120 | ``` 121 | 122 | ## Error handling 123 | 124 | When methods return an error parameter by reference, code MUST switch on the returned value and MUST NOT switch on the error variable. 125 | 126 | **For example:** 127 | ```objc 128 | NSError *error; 129 | if (![self trySomethingWithError:&error]) { 130 | // Handle Error 131 | } 132 | ``` 133 | 134 | **Not:** 135 | ```objc 136 | NSError *error; 137 | [self trySomethingWithError:&error]; 138 | if (error) { 139 | // Handle Error 140 | } 141 | ``` 142 | 143 | Some of Apple’s APIs write garbage values to the error parameter (if non-NULL) in successful cases, so switching on the error can cause false negatives (and subsequently crash). 144 | 145 | ## Methods 146 | 147 | In method signatures, there SHOULD be a space after the scope (`-` or `+` symbol). There SHOULD be a space between the method segments. 148 | 149 | **For example:** 150 | ```objc 151 | - (void)setExampleText:(NSString *)text image:(UIImage *)image; 152 | ``` 153 | 154 | ## Variables 155 | 156 | Variables SHOULD be named descriptively, with the variable’s name clearly communicating what the variable _is_ and pertinent information a programmer needs to use that value properly. 157 | 158 | **For example:** 159 | 160 | * `NSString *title`: It is reasonable to assume a “title” is a string. 161 | * `NSString *titleHTML`: This indicates a title that may contain HTML which needs parsing for display. _“HTML” is needed for a programmer to use this variable effectively._ 162 | * `NSAttributedString *titleAttributedString`: A title, already formatted for display. _`AttributedString` hints that this value is not just a vanilla title, and adding it could be a reasonable choice depending on context._ 163 | * `NSDate *now`: _No further clarification is needed._ 164 | * `NSDate *lastModifiedDate`: Simply `lastModified` can be ambiguous; depending on context, one could reasonably assume it is one of a few different types. 165 | * `NSURL *URL` vs. `NSString *URLString`: In situations when a value can reasonably be represented by different classes, it is often useful to disambiguate in the variable’s name. 166 | * `NSString *releaseDateString`: Another example where a value could be represented by another class, and the name can help disambiguate. 167 | 168 | Single letter variable names are NOT RECOMMENDED, except as simple counter variables in loops. 169 | 170 | Asterisks indicating a type is a pointer MUST be “attached to” the variable name. **For example,** `NSString *text` **not** `NSString* text` or `NSString * text`, except in the case of constants (`NSString * const NYTConstantString`). 171 | 172 | 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, see [Apple’s docs on using accessor methods in initializer methods and `dealloc`](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW6). 173 | 174 | **For example:** 175 | 176 | ```objc 177 | @interface NYTSection: NSObject 178 | 179 | @property (nonatomic) NSString *headline; 180 | 181 | @end 182 | ``` 183 | 184 | **Not:** 185 | 186 | ```objc 187 | @interface NYTSection : NSObject { 188 | NSString *headline; 189 | } 190 | ``` 191 | 192 | #### Variable Qualifiers 193 | 194 | When it comes to the variable qualifiers [introduced with ARC](https://developer.apple.com/library/ios/releasenotes/objectivec/rn-transitioningtoarc/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW4), the qualifier (`__strong`, `__weak`, `__unsafe_unretained`, `__autoreleasing`) SHOULD be placed between the asterisks and the variable name, e.g., `NSString * __weak text`. 195 | 196 | ## Naming 197 | 198 | Apple 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)). 199 | 200 | Long, descriptive method and variable names are good. 201 | 202 | **For example:** 203 | 204 | ```objc 205 | UIButton *settingsButton; 206 | ``` 207 | 208 | **Not** 209 | 210 | ```objc 211 | UIButton *setBut; 212 | ``` 213 | 214 | A three letter prefix (e.g., `NYT`) MUST be used for class names and constants, however MAY be omitted for Core Data entity names. Constants MUST be camel-case with all words capitalized and prefixed by the related class name for clarity. A two letter prefix (e.g., `NS`) is [reserved for use by Apple](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/DefiningClasses/DefiningClasses.html#//apple_ref/doc/uid/TP40011210-CH3-SW12). 215 | 216 | **For example:** 217 | 218 | ```objc 219 | static const NSTimeInterval NYTArticleViewControllerNavigationFadeAnimationDuration = 0.3; 220 | ``` 221 | 222 | **Not:** 223 | 224 | ```objc 225 | static const NSTimeInterval fadetime = 1.7; 226 | ``` 227 | 228 | Properties and local variables MUST be camel-case with the leading word being lowercase. 229 | 230 | Instance variables MUST be camel-case with the leading word being lowercase, and MUST be prefixed with an underscore. This is consistent with instance variables synthesized automatically by LLVM. **If LLVM can synthesize the variable automatically, then let it.** 231 | 232 | **For example:** 233 | 234 | ```objc 235 | @synthesize descriptiveVariableName = _descriptiveVariableName; 236 | ``` 237 | 238 | **Not:** 239 | 240 | ```objc 241 | id varnm; 242 | ``` 243 | 244 | ## Generics 245 | 246 | When declaring a property, method parameter or block parameter that is a collection type (e.g `NSDictionary`, `NSArray`, etc.), they MUST specify the compile-time type of the objects contained in them. Local declarations of collection types MAY omit the contents type specification if the context makes its contents type clear. 247 | 248 | **For example:** 249 | 250 | ```objc 251 | @interface BTNEvent: NSObject 252 | 253 | @property (nonatomic, strong) NSDictionary *properties; 254 | @property (nonatomic, strong) NSArray *flags; 255 | 256 | @end 257 | ``` 258 | 259 | **Not:** 260 | 261 | ```objc 262 | @interface BTNItem: NSObject 263 | 264 | @property (nonatomic, strong) NSDictionary *properties; 265 | @property (nonatomic, strong) NSArray *flags; 266 | 267 | @end 268 | ``` 269 | 270 | When specifying a collection’s contents type, the collection type SHOULD be immediately followed by an opening angle bracket `<`, followed by the contents type name, a single space, the pointer `*`, and the closing angle bracket. Like other [variables](#variables), there SHOULD be a single space after the closing angle bracket `>` followed by the pointer `*` attached to the variable name. 271 | 272 | **For example:** 273 | 274 | ```objc 275 | NSArray *names; 276 | 277 | - (void)setNames:(NSArray *)names; 278 | 279 | typedef void(^block)(NSArray *names); 280 | ``` 281 | 282 | **Not:** 283 | 284 | ```objc 285 | NSArray *names; 286 | NSArray *names; 287 | NSArray*names; 288 | 289 | - (void)setNames:(NSArray *)names; 290 | - (void)setNames:(NSArray *)names; 291 | - (void)setNames:(NSArray*)names; 292 | ``` 293 | 294 | An `NSDictionary` collection SHOULD use the same contents type declaration format separating types by a comma and a single space. 295 | 296 | **For example:** 297 | 298 | ```objc 299 | NSDictionary *properties; 300 | ``` 301 | 302 | **Not:** 303 | 304 | ```objc 305 | NSDictionary *properties; 306 | ``` 307 | 308 | Use your best judgement when declaring collections that contain other collections. Such declarations can quickly become verbose and less understandable. One acceptable example MAY be an `NSDictionary` with a `NSString` key type with a `NSArray`. 309 | 310 | **For example:** 311 | 312 | ```objc 313 | NSDictionary *> *properties; 314 | ``` 315 | 316 | ### Categories 317 | 318 | Categories are RECOMMENDED to concisely segment functionality and should be named to describe that functionality. 319 | 320 | **For example:** 321 | 322 | ```objc 323 | @interface UIViewController (NYTMediaPlaying) 324 | @interface NSString (NSStringEncodingDetection) 325 | ``` 326 | 327 | **Not:** 328 | 329 | ```objc 330 | @interface NYTAdvertisement (private) 331 | @interface NSString (NYTAdditions) 332 | ``` 333 | 334 | Methods and properties added in categories MUST be named with an app or organization-specific prefix. This avoids unintentionally overriding an existing method, and it reduces the chance of two categories from different libraries adding a method of the same name. (The Objective-C runtime [doesn’t specify which method will be called](https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html#//apple_ref/doc/uid/TP40011210-CH6-SW4) in the latter case, which can lead to unintended effects.) 335 | 336 | **For example:** 337 | 338 | ```objc 339 | @interface NSArray (NYTAccessors) 340 | - (id)nyt_objectOrNilAtIndex:(NSUInteger)index; 341 | @end 342 | ``` 343 | 344 | or 345 | 346 | ```objc 347 | @interface NSArray (NYTAccessors) 348 | - (id)NYT_objectOrNilAtIndex:(NSUInteger)index; 349 | @end 350 | ``` 351 | 352 | **Not:** 353 | 354 | ```objc 355 | @interface NSArray (NYTAccessors) 356 | - (id)objectOrNilAtIndex:(NSUInteger)index; 357 | @end 358 | ``` 359 | 360 | ## Comments 361 | 362 | When they are needed, comments SHOULD be used to explain **why** a particular piece of code does something. Any comments that are used MUST be kept up-to-date or deleted. 363 | 364 | Block comments are NOT RECOMMENDED, as code should be as self-documenting as possible, with only the need for intermittent, few-line explanations. This does not apply to those comments used to generate documentation. 365 | 366 | ## init and dealloc 367 | 368 | `dealloc` methods SHOULD be placed at the top of the implementation, directly after the `@synthesize` and `@dynamic` statements. `init` methods SHOULD be placed directly below the `dealloc` methods of any class. 369 | 370 | `init` methods should be structured like this: 371 | 372 | ```objc 373 | - (instancetype)init { 374 | self = [super init]; // or call the designated initializer 375 | if (self) { 376 | // Custom initialization 377 | } 378 | 379 | return self; 380 | } 381 | ``` 382 | 383 | ## Literals 384 | 385 | `NSString`, `NSDictionary`, `NSArray`, and `NSNumber` literals SHOULD be used whenever creating immutable instances of those objects. Pay special care that `nil` values not be passed into `NSArray` and `NSDictionary` literals, as this will cause a crash. 386 | 387 | **For example:** 388 | 389 | ```objc 390 | NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"]; 391 | NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"}; 392 | NSNumber *shouldUseLiterals = @YES; 393 | NSNumber *buildingZIPCode = @10018; 394 | ``` 395 | 396 | **Not:** 397 | 398 | ```objc 399 | NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil]; 400 | NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil]; 401 | NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES]; 402 | NSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018]; 403 | ``` 404 | 405 | ## `CGRect` Functions 406 | 407 | When accessing the `x`, `y`, `width`, or `height` of a `CGRect`, code MUST 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: 408 | 409 | > 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. 410 | 411 | **For example:** 412 | 413 | ```objc 414 | CGRect frame = self.view.frame; 415 | 416 | CGFloat x = CGRectGetMinX(frame); 417 | CGFloat y = CGRectGetMinY(frame); 418 | CGFloat width = CGRectGetWidth(frame); 419 | CGFloat height = CGRectGetHeight(frame); 420 | ``` 421 | 422 | **Not:** 423 | 424 | ```objc 425 | CGRect frame = self.view.frame; 426 | 427 | CGFloat x = frame.origin.x; 428 | CGFloat y = frame.origin.y; 429 | CGFloat width = frame.size.width; 430 | CGFloat height = frame.size.height; 431 | ``` 432 | 433 | ## Constants 434 | 435 | Constants are RECOMMENDED 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 MUST be declared as `static` constants. Constants MAY be declared as `#define` when explicitly being used as a macro. 436 | 437 | Use your best judgement here. If a string is used only once or twice internally in a class, it MAY be prefereable to omit the declaration of a constant if the class has thorough test coverage. 438 | 439 | **For example:** 440 | 441 | ```objc 442 | static NSString * const NYTAboutViewControllerCompanyName = @"The New York Times Company"; 443 | 444 | static const CGFloat NYTImageThumbnailHeight = 50.0; 445 | ``` 446 | 447 | **Not:** 448 | 449 | ```objc 450 | #define CompanyName @"The New York Times Company" 451 | 452 | #define thumbnailHeight 2 453 | ``` 454 | 455 | ## Enumerated Types 456 | 457 | When using `enum`s, the new fixed underlying type specification MUST be used; it provides stronger type checking and code completion. The SDK includes a macro to facilitate and encourage use of fixed underlying types: `NS_ENUM()`. 458 | 459 | **Example:** 460 | 461 | ```objc 462 | typedef NS_ENUM(NSInteger, NYTAdRequestState) { 463 | NYTAdRequestStateInactive, 464 | NYTAdRequestStateLoading 465 | }; 466 | ``` 467 | 468 | ## Bitmasks 469 | 470 | When working with bitmasks, the `NS_OPTIONS` macro MUST be used. 471 | 472 | **Example:** 473 | 474 | ```objc 475 | typedef NS_OPTIONS(NSUInteger, NYTAdCategory) { 476 | NYTAdCategoryAutos = 1 << 0, 477 | NYTAdCategoryJobs = 1 << 1, 478 | NYTAdCategoryRealState = 1 << 2, 479 | NYTAdCategoryTechnology = 1 << 3 480 | }; 481 | ``` 482 | 483 | ## Private Properties 484 | 485 | Private properties SHALL be declared in class extensions (anonymous categories) in the implementation file of a class. 486 | 487 | **For example:** 488 | 489 | ```objc 490 | @interface NYTAdvertisement () 491 | 492 | @property (nonatomic, strong) GADBannerView *googleAdView; 493 | @property (nonatomic, strong) ADBannerView *iAdView; 494 | @property (nonatomic, strong) UIWebView *adXWebView; 495 | 496 | @end 497 | ``` 498 | 499 | ## Image Naming 500 | 501 | Image names should be named consistently to preserve organization and developer sanity. Images SHOULD be named as one camel case 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. 502 | 503 | **For example:** 504 | 505 | * `RefreshBarButtonItem` / `RefreshBarButtonItem@2x` and `RefreshBarButtonItemSelected` / `RefreshBarButtonItemSelected@2x` 506 | * `ArticleNavigationBarWhite` / `ArticleNavigationBarWhite@2x` and `ArticleNavigationBarBlackSelected` / `ArticleNavigationBarBlackSelected@2x`. 507 | 508 | Images that are used for a similar purpose SHOULD be grouped in respective groups in an Images folder or Asset Catalog. 509 | 510 | ## Booleans 511 | 512 | Values MUST NOT be compared directly to `YES`, because `YES` is defined as `1`, and a `BOOL` in Objective-C is a `CHAR` type that is 8 bits long (so a value of `11111110` will return `NO` if compared to `YES`). 513 | 514 | **For an object pointer:** 515 | 516 | ```objc 517 | if (!someObject) { 518 | } 519 | 520 | if (someObject == nil) { 521 | } 522 | ``` 523 | 524 | **For a `BOOL` value:** 525 | 526 | ```objc 527 | if (isAwesome) 528 | if (!someNumber.boolValue) 529 | if (someNumber.boolValue == NO) 530 | ``` 531 | 532 | **Not:** 533 | 534 | ```objc 535 | if (isAwesome == YES) // Never do this. 536 | ``` 537 | 538 | If the name of a `BOOL` property is expressed as an adjective, the property’s name MAY omit the `is` prefix but should specify the conventional name for the getter. 539 | 540 | **For example:** 541 | 542 | ```objc 543 | @property (assign, getter=isEditable) BOOL editable; 544 | ``` 545 | 546 | _Text 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)._ 547 | 548 | ## Singletons 549 | 550 | Singleton objects SHOULD use a thread-safe pattern for creating their shared instance. 551 | ```objc 552 | + (instancetype)sharedInstance { 553 | static id sharedInstance = nil; 554 | 555 | static dispatch_once_t onceToken; 556 | dispatch_once(&onceToken, ^{ 557 | sharedInstance = [[self alloc] init]; 558 | }); 559 | 560 | return sharedInstance; 561 | } 562 | ``` 563 | This will prevent [possible and sometimes frequent crashes](http://cocoasamurai.blogspot.com/2011/04/singletons-your-doing-them-wrong.html). 564 | 565 | Any singleton MUST also be able to be created using `[[ClassName alloc] init]` and function correctly. Internal dependencies MUST be injectable to create a correctly working instance. 566 | 567 | ## Imports 568 | 569 | If there is more than one import statement, statements MUST be grouped [together](https://ashfurrow.com/blog/structuring-modern-objective-c/#grouping-import-statements). Groups MAY be commented. 570 | 571 | Note: For modules use the [@import](http://clang.llvm.org/docs/Modules.html#using-modules) syntax. 572 | 573 | ```objc 574 | // Frameworks 575 | @import QuartzCore; 576 | 577 | // Models 578 | #import "NYTUser.h" 579 | 580 | // Views 581 | #import "NYTButton.h" 582 | #import "NYTUserView.h" 583 | ``` 584 | 585 | ## Protocols 586 | 587 | In a [delegate or data source protocol](https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaEncyclopedia/DelegatesandDataSources/DelegatesandDataSources.html), the first parameter to each method SHOULD be the object sending the message. 588 | 589 | This helps disambiguate in cases when an object is the delegate for multiple similarly-typed objects, and it helps clarify intent to readers of a class implementing these delegate methods. 590 | 591 | **For example:** 592 | 593 | ```objc 594 | - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath; 595 | ``` 596 | 597 | **Not:** 598 | 599 | ```objc 600 | - (void)didSelectTableRowAtIndexPath:(NSIndexPath *)indexPath; 601 | ``` 602 | 603 | ## Xcode project 604 | 605 | The physical files SHOULD be kept in sync with the Xcode project files in order to avoid file sprawl. Any Xcode groups created SHOULD be reflected by folders in the filesystem. Code SHOULD be grouped not only by type, but also by feature for greater clarity. 606 | 607 | Target Build Setting “Treat Warnings as Errors” SHOULD be enabled. Enable as many [additional warnings](http://boredzo.org/blog/archives/2009-11-07/warnings) as possible. If you need to ignore a specific warning, use [Clang’s pragma feature](http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas). 608 | 609 | # Other Objective-C Style Guides 610 | 611 | If ours doesn’t fit your tastes, have a look at some other style guides: 612 | 613 | * [Google](http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml) 614 | * [GitHub](https://github.com/github/objective-c-style-guide) 615 | * [Adium](https://trac.adium.im/wiki/CodingStyle) 616 | * [Sam Soffes](https://gist.github.com/soffes/812796) 617 | * [CocoaDevCentral](http://cocoadevcentral.com/articles/000082.php) 618 | * [Luke Redpath](http://lukeredpath.co.uk/blog/2011/06/28/my-objective-c-style-guide/) 619 | * [Marcus Zarra](http://www.cimgf.com/zds-code-style-guide/) 620 | * [Wikimedia](https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/ObjectiveCStyleGuide) 621 | --------------------------------------------------------------------------------