标签:
1 # 译者的话 2 3 4 5 代码风格的重要性对于一个团队和项目来说不言而喻。网上有许多 Objective-C 的代码风格,但这份简洁而又最符合苹果的规范,同时有助于养成良好的代码习惯,也是我们团队一直遵循的代码风格。 6 7 8 9 原文在[这里][original_link]。 10 11 本人才疏学浅,如果有任何翻译不当欢迎在 [Issues][Issues_link] 中反馈或者直接 [Fork][Fork_link] 。 12 13 14 15 [original_link]:https://github.com/NYTimes/objective-c-style-guide 16 17 18 19 [Issues_link]:https://github.com/VincentSit/NYTimes-Objective-C-Style-Guide-ZH/issues 20 21 22 23 [Fork_link]:https://github.com/NYTimes/objective-c-style-guide/fork 24 25 26 27 ---- 28 29 30 31 # 纽约时报 移动团队 Objective-C 规范指南 32 33 34 35 这份规范指南概括了纽约时报 iOS 团队的代码约定。 36 37 38 39 ## 介绍 40 41 42 43 关于这个编程语言的所有规范,如果这里没有写到,那就在苹果的文档里: 44 45 46 47 * [Objective-C 编程语言][Introduction_1] 48 49 * [Cocoa 基本原理指南][Introduction_2] 50 51 * [Cocoa 编码指南][Introduction_3] 52 53 * [iOS 应用编程指南][Introduction_4] 54 55 56 57 [Introduction_1]:http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html 58 59 60 61 [Introduction_2]:https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/Introduction.html 62 63 64 65 [Introduction_3]:https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html 66 67 68 69 [Introduction_4]:http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/Introduction/Introduction.html 70 71 72 73 74 75 ## 目录 76 77 78 79 * [点语法](#点语法) 80 81 * [间距](#间距) 82 83 * [条件判断](#条件判断) 84 85 * [三目运算符](#三目运算符) 86 87 * [错误处理](#错误处理) 88 89 * [方法](#方法) 90 91 * [变量](#变量) 92 93 * [命名](#命名) 94 95 * [注释](#注释) 96 97 * [Init 和 Dealloc](#init-和-dealloc) 98 99 * [字面量](#字面量) 100 101 * [CGRect 函数](#CGRect-函数) 102 103 * [常量](#常量) 104 105 * [枚举类型](#枚举类型) 106 107 * [位掩码](#位掩码) 108 109 * [私有属性](#私有属性) 110 111 * [图片命名](#图片命名) 112 113 * [布尔](#布尔) 114 115 * [单例](#单例) 116 117 * [导入](#导入) 118 119 * [Xcode 工程](#Xcode-工程) 120 121 122 123 ## 点语法 124 125 126 127 应该 **始终** 使用点语法来访问或者修改属性,访问其他实例时首选括号。 128 129 130 131 **推荐:** 132 133 ```objc 134 135 view.backgroundColor = [UIColor orangeColor]; 136 137 [UIApplication sharedApplication].delegate; 138 139 ``` 140 141 142 143 **反对:** 144 145 ```objc 146 147 [view setBackgroundColor:[UIColor orangeColor]]; 148 149 UIApplication.sharedApplication.delegate; 150 151 ``` 152 153 154 155 ## 间距 156 157 158 159 * 一个缩进使用 4 个空格,永远不要使用制表符(tab)缩进。请确保在 Xcode 中设置了此偏好。 160 161 * 方法的大括号和其他的大括号(`if`/`else`/`switch`/`while` 等等)始终和声明在同一行开始,在新的一行结束。 162 163 164 165 **推荐:** 166 167 ```objc 168 169 if (user.isHappy) { 170 171 // Do something 172 173 } 174 175 else { 176 177 // Do something else 178 179 } 180 181 ``` 182 183 * 方法之间应该正好空一行,这有助于视觉清晰度和代码组织性。在方法中的功能块之间应该使用空白分开,但往往可能应该创建一个新的方法。 184 185 * `@synthesize` 和 `@dynamic` 在实现中每个都应该占一个新行。 186 187 188 189 190 191 ## 条件判断 192 193 194 195 条件判断主体部分应该始终使用大括号括住来防止[出错][Condiationals_1],即使它可以不用大括号(例如它只需要一行)。这些错误包括添加第二行(代码)并希望它是 if 语句的一部分时。还有另外一种[更危险的][Condiationals_2],当 if 语句里面的一行被注释掉,下一行就会在不经意间成为了这个 if 语句的一部分。此外,这种风格也更符合所有其他的条件判断,因此也更容易检查。 196 197 198 199 **推荐:** 200 201 ```objc 202 203 if (!error) { 204 205 return success; 206 207 } 208 209 ``` 210 211 212 213 **反对:** 214 215 ```objc 216 217 if (!error) 218 219 return success; 220 221 ``` 222 223 224 225 或 226 227 228 229 ```objc 230 231 if (!error) return success; 232 233 ``` 234 235 236 237 238 239 [Condiationals_1]:(https://github.com/NYTimes/objective-c-style-guide/issues/26#issuecomment-22074256) 240 241 [Condiationals_2]:http://programmers.stackexchange.com/a/16530 242 243 244 245 ### 三目运算符 246 247 248 249 三目运算符,? ,只有当它可以增加代码清晰度或整洁时才使用。单一的条件都应该优先考虑使用。多条件时通常使用 if 语句会更易懂,或者重构为实例变量。 250 251 252 253 **推荐:** 254 255 ```objc 256 257 result = a > b ? x : y; 258 259 ``` 260 261 262 263 **反对:** 264 265 ```objc 266 267 result = a > b ? x = c > d ? c : d : y; 268 269 ``` 270 271 272 273 ## 错误处理 274 275 276 277 当引用一个返回错误参数(error parameter)的方法时,应该针对返回值,而非错误变量。 278 279 280 281 **推荐:** 282 283 ```objc 284 285 NSError *error; 286 287 if (![self trySomethingWithError:&error]) { 288 289 // 处理错误 290 291 } 292 293 ``` 294 295 296 297 **反对:** 298 299 ```objc 300 301 NSError *error; 302 303 [self trySomethingWithError:&error]; 304 305 if (error) { 306 307 // 处理错误 308 309 } 310 311 ``` 312 313 一些苹果的 API 在成功的情况下会写一些垃圾值给错误参数(如果非空),所以针对错误变量可能会造成虚假结果(以及接下来的崩溃)。 314 315 316 317 ## 方法 318 319 320 321 在方法签名中,在 -/+ 符号后应该有一个空格。方法片段之间也应该有一个空格。 322 323 324 325 **推荐:** 326 327 ```objc 328 329 - (void)setExampleText:(NSString *)text image:(UIImage *)image; 330 331 ``` 332 333 334 335 ## 变量 336 337 338 339 变量名应该尽可能命名为描述性的。除了 `for()` 循环外,其他情况都应该避免使用单字母的变量名。 340 341 星号表示指针属于变量,例如:`NSString *text` 不要写成 `NSString* text` 或者 `NSString * text` ,常量除外。 342 343 尽量定义属性来代替直接使用实例变量。除了初始化方法(`init`, `initWithCoder:`,等), `dealloc` 方法和自定义的 setters 和 getters 内部,应避免直接访问实例变量。更多有关在初始化方法和 dealloc 方法中使用访问器方法的信息,参见[这里][Variables_1]。 344 345 346 347 348 349 **推荐:** 350 351 352 353 ```objc 354 355 @interface NYTSection: NSObject 356 357 358 359 @property (nonatomic) NSString *headline; 360 361 362 363 @end 364 365 ``` 366 367 368 369 **反对:** 370 371 372 373 ```objc 374 375 @interface NYTSection : NSObject { 376 377 NSString *headline; 378 379 } 380 381 ``` 382 383 384 385 [Variables_1]:https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW6 386 387 388 389 #### 变量限定符 390 391 392 393 当涉及到[在 ARC 中被引入][Variable_Qualifiers_1]变量限定符时, 394 395 限定符 (`__strong`, `__weak`, `__unsafe_unretained`, `__autoreleasing`) 应该位于星号和变量名之间,如:`NSString * __weak text`。 396 397 398 399 [Variable_Qualifiers_1]:(https://developer.apple.com/library/ios/releasenotes/objectivec/rn-transitioningtoarc/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW4) 400 401 402 403 ## 命名 404 405 406 407 尽可能遵守苹果的命名约定,尤其那些涉及到[内存管理规则][Naming_1],([NARC][Naming_2])的。 408 409 410 411 长的和描述性的方法名和变量名都不错。 412 413 414 415 **推荐:** 416 417 418 419 ```objc 420 421 UIButton *settingsButton; 422 423 ``` 424 425 426 427 **反对:** 428 429 430 431 ```objc 432 433 UIButton *setBut; 434 435 ``` 436 437 类名和常量应该始终使用三个字母的前缀(例如 `NYT`),但 Core Data 实体名称可以省略。为了代码清晰,常量应该使用相关类的名字作为前缀并使用驼峰命名法。 438 439 440 441 **推荐:** 442 443 444 445 ```objc 446 447 static const NSTimeInterval NYTArticleViewControllerNavigationFadeAnimationDuration = 0.3; 448 449 ``` 450 451 452 453 **反对:** 454 455 456 457 ```objc 458 459 static const NSTimeInterval fadetime = 1.7; 460 461 ``` 462 463 464 465 属性和局部变量应该使用驼峰命名法并且首字母小写。 466 467 468 469 为了保持一致,实例变量应该使用驼峰命名法命名,并且首字母小写,以下划线为前缀。这与 LLVM 自动合成的实例变量相一致。 470 471 **如果 LLVM 可以自动合成变量,那就让它自动合成。** 472 473 474 475 **推荐:** 476 477 478 479 ```objc 480 481 @synthesize descriptiveVariableName = _descriptiveVariableName; 482 483 ``` 484 485 486 487 **反对:** 488 489 490 491 ```objc 492 493 id varnm; 494 495 ``` 496 497 498 499 [Naming_1]:https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html 500 501 502 503 [Naming_2]:http://stackoverflow.com/a/2865194/340508 504 505 506 507 ## 注释 508 509 510 511 当需要的时候,注释应该被用来解释 **为什么** 特定代码做了某些事情。所使用的任何注释必须保持最新否则就删除掉。 512 513 514 515 通常应该避免一大块注释,代码就应该尽量作为自身的文档,只需要隔几行写几句说明。这并不适用于那些用来生成文档的注释。 516 517 518 519 520 521 ## init 和 dealloc 522 523 524 525 `dealloc` 方法应该放在实现文件的最上面,并且刚好在 `@synthesize` 和 `@dynamic` 语句的后面。在任何类中,`init` 都应该直接放在 `dealloc` 方法的下面。 526 527 528 529 `init` 方法的结构应该像这样: 530 531 532 533 ```objc 534 535 - (instancetype)init { 536 537 self = [super init]; // 或者调用指定的初始化方法 538 539 if (self) { 540 541 // Custom initialization 542 543 } 544 545 546 547 return self; 548 549 } 550 551 ``` 552 553 554 555 ## 字面量 556 557 558 559 每当创建 `NSString`, `NSDictionary`, `NSArray`,和 `NSNumber` 类的不可变实例时,都应该使用字面量。要注意 `nil` 值不能传给 `NSArray` 和 `NSDictionary` 字面量,这样做会导致崩溃。 560 561 562 563 **推荐:** 564 565 566 567 ```objc 568 569 NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"]; 570 571 NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"}; 572 573 NSNumber *shouldUseLiterals = @YES; 574 575 NSNumber *buildingZIPCode = @10018; 576 577 ``` 578 579 580 581 **反对:** 582 583 584 585 ```objc 586 587 NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil]; 588 589 NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil]; 590 591 NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES]; 592 593 NSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018]; 594 595 ``` 596 597 598 599 ## CGRect 函数 600 601 602 603 当访问一个 `CGRect` 的 `x`, `y`, `width`, `height` 时,应该使用[`CGGeometry` 函数][CGRect-Functions_1]代替直接访问结构体成员。苹果的 `CGGeometry` 参考中说到: 604 605 606 607 > 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. 608 609 610 611 **推荐:** 612 613 614 615 ```objc 616 617 CGRect frame = self.view.frame; 618 619 620 621 CGFloat x = CGRectGetMinX(frame); 622 623 CGFloat y = CGRectGetMinY(frame); 624 625 CGFloat width = CGRectGetWidth(frame); 626 627 CGFloat height = CGRectGetHeight(frame); 628 629 ``` 630 631 632 633 **反对:** 634 635 636 637 ```objc 638 639 CGRect frame = self.view.frame; 640 641 642 643 CGFloat x = frame.origin.x; 644 645 CGFloat y = frame.origin.y; 646 647 CGFloat width = frame.size.width; 648 649 CGFloat height = frame.size.height; 650 651 ``` 652 653 654 655 [CGRect-Functions_1]:http://developer.apple.com/library/ios/#documentation/graphicsimaging/reference/CGGeometry/Reference/reference.html 656 657 658 659 ## 常量 660 661 662 663 常量首选内联字符串字面量或数字,因为常量可以轻易重用并且可以快速改变而不需要查找和替换。常量应该声明为 `static` 常量而不是 `#define` ,除非非常明确地要当做宏来使用。 664 665 666 667 **推荐:** 668 669 670 671 ```objc 672 673 static NSString * const NYTAboutViewControllerCompanyName = @"The New York Times Company"; 674 675 676 677 static const CGFloat NYTImageThumbnailHeight = 50.0; 678 679 ``` 680 681 682 683 **反对:** 684 685 686 687 ```objc 688 689 #define CompanyName @"The New York Times Company" 690 691 692 693 #define thumbnailHeight 2 694 695 ``` 696 697 698 699 ## 枚举类型 700 701 702 703 当使用 `enum` 时,建议使用新的基础类型规范,因为它具有更强的类型检查和代码补全功能。现在 SDK 包含了一个宏来鼓励使用使用新的基础类型 - `NS_ENUM()` 704 705 706 707 **推荐:** 708 709 710 711 ```objc 712 713 typedef NS_ENUM(NSInteger, NYTAdRequestState) { 714 715 NYTAdRequestStateInactive, 716 717 NYTAdRequestStateLoading 718 719 }; 720 721 ``` 722 723 724 725 ## 位掩码 726 727 728 729 当用到位掩码时,使用 `NS_OPTIONS` 宏。 730 731 732 733 **举例:** 734 735 736 737 ```objc 738 739 typedef NS_OPTIONS(NSUInteger, NYTAdCategory) { 740 741 NYTAdCategoryAutos = 1 << 0, 742 743 NYTAdCategoryJobs = 1 << 1, 744 745 NYTAdCategoryRealState = 1 << 2, 746 747 NYTAdCategoryTechnology = 1 << 3 748 749 }; 750 751 ``` 752 753 754 755 756 757 ## 私有属性 758 759 760 761 私有属性应该声明在类实现文件的延展(匿名的类目)中。有名字的类目(例如 `NYTPrivate` 或 `private`)永远都不应该使用,除非要扩展其他类。 762 763 764 765 **推荐:** 766 767 768 769 ```objc 770 771 @interface NYTAdvertisement () 772 773 774 775 @property (nonatomic, strong) GADBannerView *googleAdView; 776 777 @property (nonatomic, strong) ADBannerView *iAdView; 778 779 @property (nonatomic, strong) UIWebView *adXWebView; 780 781 782 783 @end 784 785 ``` 786 787 788 789 ## 图片命名 790 791 792 793 图片名称应该被统一命名以保持组织的完整。它们应该被命名为一个说明它们用途的驼峰式字符串,其次是自定义类或属性的无前缀名字(如果有的话),然后进一步说明颜色 和/或 展示位置,最后是它们的状态。 794 795 796 797 **推荐:** 798 799 800 801 * `RefreshBarButtonItem` / `RefreshBarButtonItem@2x` 和 `RefreshBarButtonItemSelected` / `RefreshBarButtonItemSelected@2x` 802 803 * `ArticleNavigationBarWhite` / `ArticleNavigationBarWhite@2x` 和 `ArticleNavigationBarBlackSelected` / `ArticleNavigationBarBlackSelected@2x`. 804 805 806 807 图片目录中被用于类似目的的图片应归入各自的组中。 808 809 810 811 812 813 ## 布尔 814 815 816 817 因为 `nil` 解析为 `NO`,所以没有必要在条件中与它进行比较。永远不要直接和 `YES` 进行比较,因为 `YES` 被定义为 1,而 `BOOL` 可以多达 8 位。 818 819 820 821 这使得整个文件有更多的一致性和更大的视觉清晰度。 822 823 824 825 **推荐:** 826 827 828 829 ```objc 830 831 if (!someObject) { 832 833 } 834 835 ``` 836 837 838 839 **反对:** 840 841 842 843 ```objc 844 845 if (someObject == nil) { 846 847 } 848 849 ``` 850 851 852 853 ----- 854 855 856 857 **对于 `BOOL` 来说, 这有两种用法:** 858 859 860 861 ```objc 862 863 if (isAwesome) 864 865 if (![someObject boolValue]) 866 867 ``` 868 869 870 871 **反对:** 872 873 874 875 ```objc 876 877 if ([someObject boolValue] == NO) 878 879 if (isAwesome == YES) // 永远别这么做 880 881 ``` 882 883 884 885 ----- 886 887 888 889 如果一个 `BOOL` 属性名称是一个形容词,属性可以省略 “is” 前缀,但为 get 访问器指定一个惯用的名字,例如: 890 891 892 893 ```objc 894 895 @property (assign, getter=isEditable) BOOL editable; 896 897 ``` 898 899 900 901 内容和例子来自 [Cocoa 命名指南][Booleans_1] 。 902 903 904 905 [Booleans_1]:https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE 906 907 908 909 910 911 ## 单例 912 913 914 915 单例对象应该使用线程安全的模式创建共享的实例。 916 917 918 919 ```objc 920 921 + (instancetype)sharedInstance { 922 923 static id sharedInstance = nil; 924 925 926 927 static dispatch_once_t onceToken; 928 929 dispatch_once(&onceToken, ^{ 930 931 sharedInstance = [[self alloc] init]; 932 933 }); 934 935 936 937 return sharedInstance; 938 939 } 940 941 ``` 942 943 这将会预防[有时可能产生的许多崩溃][Singletons_1]。 944 945 946 947 [Singletons_1]:http://cocoasamurai.blogspot.com/2011/04/singletons-your-doing-them-wrong.html 948 949 950 951 ## 导入 952 953 954 955 如果有一个以上的 import 语句,就对这些语句进行[分组][Import_1]。每个分组的注释是可选的。 956 957 注:对于模块使用 [@import][Import_2] 语法。 958 959 960 961 ```objc 962 963 // Frameworks 964 965 @import QuartzCore; 966 967 968 969 // Models 970 971 #import "NYTUser.h" 972 973 974 975 // Views 976 977 #import "NYTButton.h" 978 979 #import "NYTUserView.h" 980 981 ``` 982 983 984 985 986 987 [Import_1]: http://ashfurrow.com/blog/structuring-modern-objective-c 988 989 [Import_2]: http://clang.llvm.org/docs/Modules.html#using-modules 990 991 992 993 ## Xcode 工程 994 995 996 997 为了避免文件杂乱,物理文件应该保持和 Xcode 项目文件同步。Xcode 创建的任何组(group)都必须在文件系统有相应的映射。为了更清晰,代码不仅应该按照类型进行分组,也可以根据功能进行分组。 998 999 1000 1001 1002 1003 如果可以的话,尽可能一直打开 target Build Settings 中 "Treat Warnings as Errors" 以及一些[额外的警告][Xcode-project_1]。如果你需要忽略指定的警告,使用 [Clang 的编译特性][Xcode-project_2] 。 1004 1005 1006 1007 1008 1009 [Xcode-project_1]:http://boredzo.org/blog/archives/2009-11-07/warnings 1010 1011 1012 1013 [Xcode-project_2]:http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas 1014 1015 1016 1017 1018 1019 # 其他 Objective-C 风格指南 1020 1021 1022 1023 如果感觉我们的不太符合你的口味,可以看看下面的风格指南: 1024 1025 1026 1027 * [Google](http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml) 1028 1029 * [GitHub](https://github.com/github/objective-c-conventions) 1030 1031 * [Adium](https://trac.adium.im/wiki/CodingStyle) 1032 1033 * [Sam Soffes](https://gist.github.com/soffes/812796) 1034 1035 * [CocoaDevCentral](http://cocoadevcentral.com/articles/000082.php) 1036 1037 * [Luke Redpath](http://lukeredpath.co.uk/blog/my-objective-c-style-guide.html) 1038 1039 * [Marcus Zarra](http://www.cimgf.com/zds-code-style-guide/) 1040 1041
标签:
原文地址:http://www.cnblogs.com/fshmjl/p/4852461.html