1. 总体指导原则
【规则1-1】首先是为人编写程序，其次才是计算机。
说明：这是软件开发的基本要点，软件的生命周期贯穿产品的开发、测试、生产、用户使用、版本升级和后期维护等长期过程，只有易读、易维护的软件代码才具有生命力，所以提倡写代码之前多思考，特别是逻辑复杂或者技术难点较高的地方，个人思考不清楚的，可以和团队成员进行沟通。
【规则1-2】保持代码的简明清晰，避免过分的编程技巧。
说明：简单是最美。保持代码的简单化是软件工程化的基本要求。不要过分追求技巧，否则会降低程序的可读性。
【规则1-3】编程时首先达到正确性，其次考虑效率。
说明：编程首先考虑的是满足正确性、健壮性、可维护性、可移植性等质量因素，最后才考虑程序的效率和资源占用。
【规则1-4】编写代码时要考虑到代码的可测试性。
说明：不可以测试的代码是无法保障质量的，开发人员要牢记这一点来设计、编码。实现设计功能的同时，要提供可以测试、验证的方法。
【规则1-5】函数（方法）是为一特定功能而编写，不是万能工具箱。
说明：方法是一个处理单元，是有特定功能的，所以应该很好地规划方法，不能是所有东西都放在一个方法里实现，也不能把所有东西都放在一个类里面实现(比如说VC)。
【规则1-6】鼓励多加注释。
【规则1-7】建议少用XIB，特别是XIB中的约束。
2.控制器规范
【规则2-1】不需要对外提供的方法和属性，不得在头文件(.h)中进行定义。
【规则2-2】头文件中对外提供的API，建议以方法参数的方式，不建议采用属性的方式。
说明：这是因为采用属性的方式，如果该控制器调用地方较多，每个地方的参数不一样，会造成调用方属性赋值的困惑。
【规则2-3】不建议在控制器中直接调用网络请求(HDFNet)和进行数据处理。
【规则2-4】控制器一般承载较多的逻辑处理，因此对控制器的文件结构做如下规范：
- 头文件
文件头 #import （依次为标准库头文件、非标准库头文件） 宏定义 全局数据类型 类定义
- 实现文件
文件头 #import （依次为标准库头文件、非标准库头文件） 文件内部使用的宏 文件内部使用的数据类型 全局变量 本地变量（即静态全局变量） 类的实现 #pragma mark - LifeCycle #pragma mark - Private Method #pragma mark -- UI #pragma mark -- 数据加载和解析 #pragma mark - Event #pragma mark - Delegate #pragma mark -- UITableViewDataSource #pragma mark -- UITableViewDelegate #pragma mark - Getter/Setter
【规则2-5】空行。【规则2-4】中的每一项内容之间空一行，方法之间空一行，重要的代码段之间空一行。
3.命名规范
【规则3-1】所有文件命名需要添加前缀。
【规则3-2】业务模块建议自定义一个前缀，比如家庭医生，可以加前缀HDFFamilyDoctor。
【规则3-3】命名遵循驼峰法命名规则。
说明：
- 小驼峰法：除第一个单词之外，其他单词首字母大写；
- 大驼峰法：把第一个单词的首字母也大写。
【规则3-4】类命名遵循大驼峰法规则：前缀+描述+类型。
说明：以家庭医生服务页为例，前缀为HDFFamilyDoctor，描述为Service，类型为ViewController，那么该类命名为HDFFamilyDoctorServiceViewController。
关于类型，主要有如下几类：
|
描述 |
类型 |
|---|---|
| 控制器 | ViewController |
| 表格行 | Cell |
| 视图 | View |
| 模型 | Model |
| 数据请求 | DataHelper |
【规则3-5】属性命名遵循小驼峰法规则：描述+类型简写
说明：比如定义一个姓名的标签，描述为name，类型为Label，命名为nameLabel。
关于类型缩写，主要有如下两大类：
一、Foundation类型
|
Foundation类型 |
缩写 |
|---|---|
| NSString | String |
| Integer/int | Int |
| BOOL/Boolean | Bool |
| char | Char |
| NSArray | Array |
| NSDictionary | Dic |
| NSDate | Date |
| NSObject | Obj |
二、UIKit类型
|
UIKit类型 |
简写 |
UIKit类型 |
简写 |
|---|---|---|---|
| UILabel | Label | UIButton | Btn |
| UITextView | TextView | UITextField | TextField |
| UITableView | TableView | UIImageVIew | ImageView |
| UIWebView | WebView | UIScrollView | ScrollView |
| UIViewController | VC | UITableViewCell | Cell |
【规则3-6】方法命名遵循小驼峰法规则，建议遵守如下相关细则：
- 方法的名称应全部使用有意义的单词组成，读起来像一句完整的话，能让人从名字就能知道方法的作用；
- set方法前需要添加set，get方法前不需要添加get；
- 常用的方法命名应该使用约定的动词，如initWith、insert、remove、replace等；
- init方法应该遵循Apple命名规则，返回类型使用 instancetype而不是id；
- 方法签名中，应该在方法类型(-/+ 符号)之后有一个空格。在方法各个段之间应该也有一个空格。
【规则3-7】枚举类型的类型和枚举值命名推荐使用如下格式：
typedef NS_OPTIONS(NSInteger, MASAttribute) {
MASAttributeLeft = 1 << NSLayoutAttributeLeft,
MASAttributeRight = 1 << NSLayoutAttributeRight
};
【规则3-8】图片命名采用规则：模块+功能+类型
说明：
- 模块可分为公用模块和私有模块，可自定义模块的缩写，比如说公用模块的导航栏，可以定义缩写为nav；
- 功能根据具体的用途划分，比如说返回按钮，功能可定位为back；
- 类型主要有几类：如背景(bg)，按钮(btn)等。
综上所述，如果是导航栏的返回按钮，可命名为[email protected]。
4.注释
【规则4-1】注释建议统一使用VVDocument插件。
【规则4-2】每个头文件必须添加注释，用于对该类的功能做说明。
【规则4-3】头文件中定义的属性和方法，必须添加注释。
说明：属性的注释建议在属性后使用“//<!”添加。
【规则4-4】实现文件中定义的变量、属性和自定义方法，必须添加注释。
【规则4-5】实现文件中系统方法或系统代理，不强制添加注释。
【规则4-6】实现文件方法中，对功能段代码添加注释，比如说一个视图的定义和属性设置，那么可以作为一个功能段添加注释。
【规则4-7】枚举类型、宏定义、结构体等建议添加注释。