iOS规范文档OC版

iOS规范文档OC版

目录结构规范

静态库

目录名为：Frameworks，存放所有的静态库文件

项目目录

Macro：宏定义文件夹，只放值一些自定义或第三方秘钥，其他的宏定义需放置在pch文件里

NetWorks：网络请求文件夹，放置不同网络请求的文件

Categories：分类文件

Utils：工具类文件

Models：数据模型文件

Views：视图文件

Controllers：控制器文件

Managers：管理类文件

DataBase：数据库文件（CoreData或FMDB）

扫描二维码关注公众号，回复： 22452 查看本文章

Vendors：第三方SDK

Resources：资源文件

项目目录下的子文件根据功能进行分割，不同功能模块的代码需要分别使用文件夹分开，存放在子文件下或单独创建一个主文件夹。
按大功能模块Controller至少创建一个父类 View看需求

命名规范

通用规范

通用规范是在整个项目中，所有的命名都需要遵循的规范

清晰

所有的命名要清晰且简洁，以清晰为主。要做到见名知意。命名最好以英文为主，除专有名词外，不许使用单词缩写。严禁使用中文或拼音以及拼音与英文混合的方式。

创建首页文件件====

正例：HomeViewController

反例：shouyeViewControlle

一致性

做某件事的代码通常都叫这个名字，比如tag、setStringValue，那你也这么叫。在你不确定怎么起名的时候请参照《Apple开发规范》。

驼峰原则

分为大驼峰和小驼峰，每个类型需要遵循大驼峰或小驼峰中的一种
大驼峰：首字母大写。
小驼峰：首字母小写

大驼峰：HomeViewController

小驼峰：userName

文件夹命名规范

文件夹名需要遵循大驼峰原则，且功能集合的文件夹必须使用复数形式。文件命名需要与模块的功能相对应。

类命名规范

类名需要遵循大驼峰原则。类名最好加上项目的前缀缩写，如WP+类名。当需要在其他项目使用的类，可以不加或添加规定的统一前缀。

封装通用的库，需要确认统一的前缀（WP）！

类别名规范

类别的命名主要是扩展名的命名规则，类别的扩展名必须要遵循 类名 + 标识 + 扩展功能的命名规范。

UIImage (WPAdd)

方法命名规范

方法名的命名需要遵循小驼峰原则。规范的方法名应该看起来像一个完整的句子。尽量做到读方法名便可以知道函数的作用。

/**
 发送获取地址列表请求
 */
- (void)beginSendRequestForGetAddressList

代理命名规范

代理的命名需要遵从大驼峰原则。且开始必须要遵循当前代理对象 + Delegate的命名规范。例如：LoginViewDelegate

变量命名规范

变量名需要遵循小驼峰原则。除了公认的名称外，必须使用单词的全称命名。当需要使用多个参数时，按照顺序拼接。禁止使用缩写进行拼接。普通变量无需添加下划线开头，全局变量、成员变量需要以下划线开头。

常量命名规范

常量名规范分为3种：
1、普通常量：需要遵循小驼峰原则。例如：kUserToken
1、宏定义：需要全大写，例如USER_TOKEN
2、枚举：需要遵循前缀 + 大驼峰的命名方式。例如：WPUserLoginType

图片命名

1、模块+功能命名法（公共使用：common+功能）例如：个人中心模块中我的消息按钮：personal_btn_my_message

2、单词全拼，或者大家公认无歧义的缩写（如：nav，bg，btn等）

注释规范

所有使用//进行注释的代码，//后面必须要加上空格，即// 注释。

成员变量注释规范

.h文件中，所有的属性使用 /** 注释 */的注释方法，例如：

/** 用户Id */
@property (nonatomic, copy) NSString *userId;

当需要对属性进行详细说明时可以对/** 注释 */进行换行，来分行注释

/**
 登录凭证
 每次登录时创建或者退出时删除
 */
@property (nonatomic, copy) NSString *sessionToken;

.m中的，所有属性在结尾处使用// 注释进行注释，且//与结尾处至少空一格。注释内容最好可以就近对齐，对齐可以使用Tab直接缩进对齐或使用空格键对齐，例如：

@property (nonatomic, strong) ODSTopUpCountView *topUpCountView; // 充值金额视图

@property (nonatomic, strong) ODSTopUpPaymentView *payTypeView;  // 支付方式视图

@property (nonatomic, strong) ODSTopUpBottomView *bottomView;    // 支付说明视图

非成员变量，在结尾处使用// 注释进行注释，例如：

@interface ODSTopUpViewController ()
{
    UILabel *_nameLabel; // 用户名文本
}

@end

方法注释规范

方法注释统一使用系统注释方法CMD + Opt + ?,当方法的参数名不重要时则可以删除。重要的参数名必须要要进行注释。
除系统方法外，自定义的方法必须要注释!
复杂的逻辑处理最好也要加上必要的注释说明，说明主要的处理逻辑

方法与方法间，如果后面一个方法有注释，则换一行，没有注释则需要换两行

代码组织

.m文件中必须使用#pragma mark -进行方法分组。Controller中最好使用一下的方法进行分组：

#pragma mark - - - - - - - - - - - - - - - - - Init And Dealloc - - - - - - - - - - - - - - - - -
#pragma mark - - - - - - - - - - - - - - - - - Life Cycle - - - - - - - - - - - - - - - - -
#pragma mark - - - - - - - - - - - - - - - - - Data Request - - - - - - - - - - - - - - - - -
#pragma mark - - - - - - - - - - - - - - - - - Event Response - - - - - - - - - - - - - - - - -
#pragma mark - - - - - - - - - - - - - - - - - Delegate Response - - - - - - - - - - - - - - - - -
#pragma mark - - - - - - - - - - - - - - - - - NSNotification Response - - - - - - - - - - - - - - - - 
#pragma mark - - - - - - - - - - - - - - - - - Public Events - - - - - - - - - - - - - - - - -
#pragma mark - - - - - - - - - - - - - - - - - Private Events - - - - - - - - - - - - - - - - -
#pragma mark - - - - - - - - - - - - - - - - - Setter and Getter - - - - - - - - - - - - - - - - -

代码规范

删除多余的空格

属性变量

使用@property时，括号中的nonatomic、assign、strong等，中间用,隔开时，逗号后面必须空一格。后面的类名与()必须空一格。

@property (nonatomic, copy) NSString *userId;

方法规范

有处理逻辑的方法左侧的{需要换行。没有处理逻辑时，则使用{}，且方法前的-、+必须与后面的()空一格具。体如下所示：

- (void)loginButtonClick
{
    // 执行逻辑
}

- (void)loginButtonClick
{}

控制语句

1、switch块内通过break/return来终止
在一个switch块内，每个case要么通过break/return来终止，要么注释说明程序将继续执行到哪一个case为止；在一个switch块内，都必须包含一个default语句并且放在最后，即使它什么代码也没有。

2、在if/for/while/switch语句中使用大括号
条件语句体应该总是被大括号包围。尽管有时候你可以不使用大括号（比如，条件语句体只有一行内容），但是这样做会带来问题隐患。比如，增加一行代码时，你可能会误以为它是 if 语句体里面的。此外，更危险的是，如果把 if 后面的那行代码注释掉，之后的一行代码会成为 if 语句里的代码。

3、推荐尽量少用else，例如：

if (isLogin) {

    //处理逻辑
    return;
}

// else的逻辑

4、if/for/while/switch语句中，if/for/while/switch与后面的()必须要空一格，()与左侧{必须空一格。且if/for/while/switch语句中左侧的{不换行。

5、if的条件判断中尽量不要使用函数方法作为判断，应新建一个BOOL类型的值接收，例如

正例: 
    BOOL success = [self checkSaveIsSuccess];
    if (success) {
        
        // 处理逻辑
        
    } else {
    
    }
    
反例：
    if ([self checkSaveIsSuccess]) {
        
        // 处理逻辑
        
    } else {
    
    }

操作符

除了一元操作符外，所有操作符两侧的元素必须要与操作符空一格。

封装

当项目或.m文件中，同一段代码出现三次以上的时候，则需要对这段代码进行封装。