浙江我财 Objective-C 编码规范

• 浙江我财iOS团队的编码规范
• 代码Review基本依据
• 适用范围
  
  • 适用人员: 浙江我财iOS团队
  • 适用项目: 公司内部所有以Objective-C开发的企业项目、产品和内部开源项目

介绍

关于这个编程语言的所有规范，如果这里没有写到，那就在苹果的文档里：

• Objective-C 编程语言
• Cocoa 基本原理指南
• Cocoa 编码指南
• iOS 应用编程指南

目录

• 基本原则
• 点语法
• 间距
• 条件判断
  
  • 三目运算符
• 错误处理
• 方法
• 变量
• 命名
• 注释
• 代码标记
• Init
• 字面量
• CGRect 函数
• 常量
• 枚举类型
• 位掩码
• 私有属性
• 通知
• block
• 图片命名
• 布尔
• 单例
• Xcode 工程

基本原则

• 规范要求等级说明
  
  • 始终：务必要求按照此规范处理
  • 推荐：强烈建议按照此规范处理(默认等级)
  • 反对：一定不能出现此编码
• 命名要做到见名知意，采用驼峰法

• 使用完整单词，避免缩写词

• 始终使用Tab，不是用空格，一个制表符（tab）代表4个空格，可以在Xcode->Preferneces->Text Editing -> Inenttion -> Tab width进行设置。

• 始终单行不超过100个字符,可以在Xcode->Preferneces->Text Editing -> Editing -> Page guide at column进行设置。
• 始终单个方法代码行数不能超过200行,方法体的规模应尽可能小，一个方法做一件事情，不要把多个任务组合到一个方法中

• 始终单个类实现代码行数不能超过1000行

• 推荐功能相同的代码不出现多次

点语法

应该 始终 使用点语法来访问或者修改属性，访问其他实例时首选括号。

推荐：

view.backgroundColor = [UIColor orangeColor];
[UIApplication sharedApplication].delegate;

反对：

[view setBackgroundColor:[UIColor orangeColor]];
UIApplication.sharedApplication.delegate;

间距

• 一个缩进使用一个制表符（tab）缩进，始终不要使用四个空格。
• 方法的大括号和其他的大括号（if/else/switch/while 等等） 始终 和声明在同一行开始，在新的一行结束。

推荐：

if (user.isHappy) {
// Do something
} else {
// Do something else
}

反对：

if (user.isHappy) 
{
// Do something
}else 
{
// Do something else
}

• 方法之间应该正好空一行，这有助于视觉清晰度和代码组织性。在方法中的功能块之间应该使用空白分开，但往往可能应该创建一个新的方法。

• @synthesize 和 @dynamic 在实现中每个 始终 都应该占一个新行。

条件判断

条件判断主体部分应该始终使用大括号括住来防止出错，即使它可以不用大括号（例如它只需要一行）。这些错误包括添加第二行（代码）并希望它是 if 语句的一部分时。还有另外一种更危险的，当 if 语句里面的一行被注释掉，下一行就会在不经意间成为了这个 if 语句的一部分。此外，这种风格也更符合所有其他的条件判断，因此也更容易检查。

推荐：

if (!error) {
    return success;
}

反对：

if (!error)
    return success;

或

反对：

if (!error) return success;

三目运算符

三目运算符，? ，只有当它可以增加代码清晰度或整洁时才使用。单一的条件都应该优先考虑使用。多条件时通常使用 if 语句会更易懂，或者重构为实例变量。

推荐：

result = a > b ? x : y;

反对：

result = a > b ? x = c > d ? c : d : y;

错误处理

当引用一个返回错误参数（error parameter）的方法时，应该针对返回值，而非错误变量。

推荐：

NSError *error;
if (![self trySomethingWithError:&error]) {
    // 处理错误
}

反对：

NSError *error;
[self trySomethingWithError:&error];
if (error) {
    // 处理错误
}

一些苹果的 API 在成功的情况下会写一些垃圾值给错误参数（如果非空），所以针对错误变量可能会造成虚假结果（以及接下来的崩溃）。

方法

在方法签名中，在 -/+ 符号后应该有一个空格。方法片段之间也应该有一个空格。

始终：

- (void)setExampleText:(NSString *)text image:(UIImage *)image;

反对：

-(void) setExampleText:(NSString *)text image:(UIImage *)image;
-(void)setExampleText:(NSString *)text image:(UIImage *)image;

变量

• 变量名应该尽可能命名为描述性的。除了 for() 循环外，其他情况都应该避免使用单字母的变量名。星号表示指针属于变量，例如：NSString *text 不要写成 NSString* text 或者 NSString * text ，常量除外。

• 尽量定义属性来代替直接使用实例变量。

• 除了初始化方法（init， initWithCoder:，等）， dealloc 方法和自定义的 setters 和 getters 内部，应避免直接访问实例变量。更多有关在初始化方法和 dealloc 方法中使用访问器方法的信息，参见这里。

推荐：

@interface WCSection: NSObject
@property (nonatomic) NSString *headline;
@end

反对：

@interface WCSection : NSObject {
    NSString *headline;
}

• 变量限定符

当涉及到在 ARC 中被引入变量限定符时，
限定符 (__strong, __weak, __unsafe_unretained, __autoreleasing) 应该位于星号和变量名之间，如：NSString * __weak text。

命名

• 尽可能遵守苹果的命名约定，尤其那些涉及到内存管理规则，（NARC）的。

长的和描述性的方法名和变量名都不错。

推荐：

UIButton *settingsButton;

反对：

UIButton *setBut;
UIButton *setting;
UIButton *set;

• 类名和常量应该始终使用前缀（例如 WC），但 Core Data 实体名称可以省略。为了代码清晰，常量应该使用相关类的名字作为前缀并使用驼峰命名法。

推荐：

static const NSTimeInterval WCArticleViewControllerNavigationFadeAnimationDuration = 0.3;

反对：

static const NSTimeInterval fadetime = 1.7;

• 属性和局部变量应该使用驼峰命名法并且首字母小写。

注释

• 当需要的时候，注释应该被用来解释 为什么 特定代码做了某些事情。所使用的任何注释必须保持最新否则就删除掉。

• 通常应该避免一大块注释，代码就应该尽量作为自身的文档，只需要隔几行写几句说明。这并不适用于那些用来生成文档的注释。

• Xcode注释插件采用VVDocumenter，注释直接通过插件生成

• .h/.m文件注释,公司内项目均版权属于浙江我财网络科技有限公司

推荐:

//
//  LoginViewController.h
//  [ProjectName]
//
//  Created by [Author] on 15-7-16.
//  Copyright (c) 2015年 浙江我财网络科技有限公司. All rights reserved.

代码标记

• 程序编码过程中，我们可以通过一些标注，来提示自己有些事情是需要以后来处理的，为了防止遗漏，加上TODO、FIXME、!!!、???和waring是很有必要的，我们可以通过下面的方式添加对应的提醒：

   // TODO: 处理异常情况 (标记待处理的事情)
   // FIXME: 此处需要清除缓存(标记说明此处还需要修复的内容)
   // !!!: 此处逻辑不严谨，待完善 (特别注意)
   // ???: 这块的实现上还存在难度，待研究跟进 (疑问或有待研究)
   #warning 此处在特定情况下会出现异常，提交版本前一定要处理 (主动设置警告)

前四种为备注说明，并且在预览方法时会清晰显示出来，后面warnning，是在编译程序后都会直接作为一个警告出现在编译结果中。
在实际开发中，如果开发到中途，要需要处理的，务必加上对应的标志，防止再次来编辑时遗漏。另外，在提交版本前，一定要对这些标志进行一次检查，warnning能很明显的发现，其他四种可以采用插件Xcode插件XToDo来查找。

init

• init 方法的结构应该像这样：

- (instancetype)init {
    self = [super init]; // 或者调用指定的初始化方法
    if (self) {
        // Custom initialization
    }
    return self;
}

字面量

每当创建 NSString， NSDictionary， NSArray，和 NSNumber 类的不可变实例时，都应该使用字面量。要注意 nil 值不能传给 NSArray 和 NSDictionary 字面量，这样做会导致崩溃。

推荐：

NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingZIPCode = @10018;

反对：

NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];
NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];
NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];
NSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018];

CGRect 函数

当访问一个 CGRect 的 x， y， width， height 时，应该使用CGGeometry 函数代替直接访问结构体成员。苹果的 CGGeometry 参考中说到：

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.

推荐：

CGRect frame = self.view.frame;
CGFloat x = CGRectGetMinX(frame);
CGFloat y = CGRectGetMinY(frame);
CGFloat width = CGRectGetWidth(frame);
CGFloat height = CGRectGetHeight(frame);

反对：

CGRect frame = self.view.frame;
CGFloat x = frame.origin.x;
CGFloat y = frame.origin.y;
CGFloat width = frame.size.width;
CGFloat height = frame.size.height;

常量

常量首选内联字符串字面量或数字，因为常量可以轻易重用并且可以快速改变而不需要查找和替换。常量应该声明为 static 常量而不是 #define ，除非非常明确地要当做宏来使用。

推荐：

static NSString * const WCAboutViewControllerCompanyName = @"ZJWoCai Company";
static const CGFloat WCImageThumbnailHeight = 50.0;

反对：

#define CompanyName @"ZJWoCai Company"
#define thumbnailHeight 2

枚举类型

当使用 enum 时，建议使用新的基础类型规范，因为它具有更强的类型检查和代码补全功能。现在 SDK 包含了一个宏来鼓励使用使用新的基础类型 - NS_ENUM()

推荐：

typedef NS_ENUM(NSInteger, WCAdRequestState) {
    WCAdRequestStateInactive,
    WCAdRequestStateLoading
};

位掩码

当用到位掩码时，使用 NS_OPTIONS 宏。

举例：

typedef NS_OPTIONS(NSUInteger, WCAdCategory) {
WCAdCategoryAutos      = 1 << 0,
WCAdCategoryJobs       = 1 << 1,
WCAdCategoryRealState  = 1 << 2,
WCAdCategoryTechnology = 1 << 3
};

私有属性

私有属性应该声明在类实现文件的延展（匿名的类目）中。有名字的类目（例如 WCPrivate 或 private）永远都不应该使用，除非要扩展其他类。

推荐：

@interface WCAdvertisement ()
@property (nonatomic, strong) GADBannerView *googleAdView;
@property (nonatomic, strong) ADBannerView *iAdView;
@property (nonatomic, strong) UIWebView *adXWebView;
@end

通知

• 基本命名格式是：[与通知相关的类名] + [Did | Will] + [UniquePartOfName] + Notification

推荐：

NSApplicationDidBecomeActiveNotification
NSWindowDidMiniaturizeNotification
NSTextViewDidChangeSelectionNotification

• 通知名称 始终 使用常量定义， 反对 直接使用字符串或使用宏Define定义

推荐:

//.h文件中声明
extern NSString * const UserProfileImageDidLoadNotification;
//.m中实现
NSString * const UserProfileImageDidLoadNotification = @"com.alamofire.user.profile-image.loaded";

反对:

#Define   UserProfileImageDidLoadNotification = “com.alamofire.user.profile-image.loaded”;

block

• 项目中常见block定义方式

推荐

typedef void(^SDWebImageCompletedBlock)(UIImage *image, NSError *error, SDImageCacheType cacheType);
typedef void(^SDWebImageDownloaderProgressBlock)(NSUInteger receivedSize, long long expectedSize);

block类型命名规则约定：[类名]+[状态]（可选 + [条件描述，如withxxx]）+ Block。

图片命名

• 图片名称应该被统一命名以保持组织的完整。它们应该被命名为一个说明它们用途的驼峰式字符串，其次是自定义类或属性的无前缀名字（如果有的话），然后进一步说明颜色 和/或 展示位置，最后是它们的状态。

推荐：

* `RefreshBarButtonItem` / `RefreshBarButtonItem@2x` 和 `RefreshBarButtonItemSelected` / `RefreshBarButtonItemSelected@2x`
* `ArticleNavigationBarWhite` / `ArticleNavigationBarWhite@2x` 和 `ArticleNavigationBarBlackSelected` / `ArticleNavigationBarBlackSelected@2x`.

图片目录中被用于类似目的的图片应归入各自的组中。

布尔

因为 nil 解析为 NO，所以没有必要在条件中与它进行比较。永远不要直接和 YES 进行比较，因为 YES 被定义为 1，而 BOOL 可以多达 8 位。

这使得整个文件有更多的一致性和更大的视觉清晰度。

推荐：

if (!someObject) {
}

反对：

if (someObject == nil) {
}

对于 BOOL 来说, 这有两种用法:

推荐：

if (isAwesome)
if (![someObject boolValue])

反对：

if ([someObject boolValue] == NO)
if (isAwesome == YES) // 永远别这么做

如果一个 BOOL 属性名称是一个形容词，属性可以省略 “is” 前缀，但为 get 访问器指定一个惯用的名字，例如：

@property (assign, getter=isEditable) BOOL editable;

内容和例子来自 Cocoa 命名指南 。

单例

单例对象应该使用线程安全的模式创建共享的实例。

推荐:

+ (instancetype)sharedInstance {
   static id sharedInstance = nil;
   static dispatch_once_t onceToken;
   dispatch_once(&onceToken, ^{
      sharedInstance = [[self alloc] init];
   });
   return sharedInstance;
}

这将会预防有时可能产生的许多崩溃。

Xcode 工程

• 为了避免文件杂乱，物理文件应该保持和 Xcode 项目文件同步。
• Xcode 创建的任何组（group）都必须在文件系统有相应的映射。
• 为了更清晰，代码不仅应该按照类型进行分组，也可以根据功能进行分组。
• 如果可以的话，尽可能一直打开 target Build Settings 中 "Treat Warnings as Errors" 以及一些额外的警告。如果你需要忽略指定的警告,使用 Clang 的编译特性 。
• 工程项目内警告始终需要处理.

参考

本编码规范主要参考下面几则规范，有兴趣看看对应的风格指南：

• NYTimes
• Google
• GitHub
• Adium
• Sam Soffes
• CocoaDevCentral
• Luke Redpath
• Marcus Zarra