IOS设备尺寸、设计尺寸及编码规范
参考
编码规范
命名规范
- 小驼峰原则：第一个单词首字母小写，其余都大写。例如：userName
项目命名
- 项目命名尊享大驼峰原则。例如：HuiBoProject
Bundle Identifier 命名
- Bundle Identifier：采用反域名命名规范，全部采用小写字母，以域名后缀+公司顶级域名+应用名形式命名，例如：com.company.huiboproject
类名
- 类的命名都遵循大驼峰命名。一般是：前缀 + 功能 + 类型。例如：HB + Login + ViewController
- 常用控件命名类型
| 控件名 | 类型 | 示例 |
|---|---|---|
| UIViewController | ViewController | HBBaseViewController |
| UView | View | HBBaseView |
| UITableView | TableView | HBOrderTableView |
| UITableViewCell | Cell | HBOrderListCell |
| UIButton | Button | HBSuccessButton |
| UILabel | Label | HBSuccessLabel |
| UIImageView | ImgView | HBGoodsImgView |
| UITextField | TextField | HBNameTextField |
| UITextView | TextView | HBSuggestTextView |
- 其它类
| 功能 | 类型 | 示例 |
|---|---|---|
| 工具类 | Tool | HBOrderTool |
| 代理类 | Delegate | HBOrderListDelegate |
| 管理类 | Manager | HBOrderListModel |
| 模型类 | Model | HBOrderListModel |
| Service类 | Service | HBOrderService |
| 布局类 | Layout | HBHomeLayout |
| 数据库类 | DataBase、表名+DBHelper | HBFriendDataBase、HBUserTableDBHelper |
| 类目 | XXX+（范围，例如Extension， Additions 或者功能，例如Frame，Nib，Block） | HBUIButton+Additions、HBUIButton+Block |
UIViewController请按照如下分类
#pragma mark - life cycle
#pragma mark - event response
#pragma mark - UITableViewDelegate && UITableViewDataSource
（代理顺序往下排列）
#pragma mark - getters and setters
#pragma mark - private
注意：所有视图或者对象调用的时候全部使用self.textBtn这样的方式
变量和方法
变量和方法的命名都遵循小驼峰命名。例如：textVariableStr, - (void)textAction响应事件。尽量使用有意义的名字命名，拒绝使用i,j等无意义字符命名。类的命名首字母大写，其他变量的命名首字符小写，并使用驼峰式分割单词。
变量命名对照表（如果用到下表中没有列举出来，请去掉UI、NS遵循实际规则即可。或者一看就知道的通用简写）
方法命名对照表（方法多为动词或动名词）
| 功能 | 示例 |
|---|---|
| - (id)initXX | 初始化相关方法,使用init为前缀标识，如初始化布局- (id)initView |
| - (BOOL)isXX | 方法返回值为boolean型的请使用is前缀标识 |
| - (UIView *)getXX | 返回某个值的方法，使用get为前缀标识 |
| - (void)setXX | 设置某个属性值或者相关数据 |
| - (void)updateXX | 更新数据 |
| - (void)saveXX | 保存数据 |
| - (void)drawXX | 绘制相关，使用draw前缀标识 |
| - (void)clearXX | 清除数据 |
| - (void)XXXAction | 响应事件，使用Action为后缀标识 |
| - (void)loadData | 加载数据（一般情况下VC中都会有这个方法） |
| - (void)loadMoreData | 加载更多数据 |
| - (void)setupUI | 加载布局（一般情况下VC中都会有这个方法） |
- 函数调用时所有参数在同一行。如果参数过多，则可以每行一个参数，每个参数以冒号对齐
- 任意函数长度不得超过70行。（其实很容易就超过70行，这就要考虑代码抽取了。）
- 在每个方法的定义前留白一行，也就是在方法和方法之间留空一行
- 功能相近的方法要放在一起，并推荐使用#pragma mark - ***或者 // MARK: ***来导航代码，切分代码块。这样可以方便函数的查找。并且可以使用快捷键control+6 来快速查找方法的位置。
- 二元运算符和参数之间要有一个空格，如赋值号=左右各留一个空格
- 一元运算符和参数之间不放置空格，比如！非运算符，&按位与，|按位或
- 强制类型转换和参数之间不放置空格
- 长的变量值应该拆分为多行。尤其体现在使用数组或者字典
常量
- 全局常量：小写k+大驼峰 即为：extern const NSString *kUserAgeKey
- 宏：工程前+缀全大写，下划线隔开 即为：#define HB_USER_AGE_KE @“user_age_Key”
- 枚举：需要遵循前缀 + 大驼峰的命名方式。例如：HBUserLoginType
参数名
- 参数名以小驼峰命名，尽量参考苹果原生方法风格编写。尽量可读性好，看到方法名就知道这个方法是用来干什么的。参数应该避免用单个字符命名。例：- (void)setDataImageUrl:(NSString *)imageUrl name:(NSString *)nameStr content:(NSString *)contentStr
资源文件规范
- 全部小写，采用下划线命名法，加前缀区分。所有的资源文件都需要加上工程前缀（小写形式）。
命名模式：可加后缀small表示小图,big表示大图，逻辑名称可由多个单词加下划线组成，采用以下规则：
用途模块名逻辑名称
用途模块名颜色
用途逻辑名称
用途颜色
文件夹命名
- 创建文件夹最好创建实体文件夹，找到工程目录，创建相应文件夹并拖入工程。文件夹命名使用相应模块结构分层的英文，首字母要大写。例：Model，View，Controller，Tool，Other，Service等等。
版本规范
- 采用A.B.C 三位数字命名，比如：1.0.2
第三方库规范
- 项目使用cocoapods统一管理开源第三库文件，不需要手动导入和手动添加依赖库。如果第三方不支持cocoapods，可手动导入工程
注释规范
- 方法注释，方法外部统一用option + command + /，方法内部统一用//注释。
模型注释
- 每个model中的，包含的每个属性，都必须要写上相对应的注释，用///注释。阅读者一看这个model，就清楚知道model中的每个字段代表的意思，用来做什么事情的。
编码规范
- 所有的方法之间空一行。
- 所有的代码块之间空一行，删除多余的注释。
- 所有自定义的方法需要给出注释。
- 代码后的’{‘不需要独占一行，包括方法之后，if，switch等。
- 必须要统一的要求，属性的定义请按照下图property之后，空一格，括号之后空一格，写上类名，空一格之后跟上*和属性名。
- 遵循一般代码规范，多模仿苹果API。
- 删除不用的代码。
- 如果有方法一直不会用到，请删除（除工具类）。
- 没有执行任何业务逻辑的方法，请删除或给予注释，删除多余的资。源或文件，添加必要的注释。
- 比较大的代码块需要给出注释
其它规范
项目统一使用Masonry和xib结合的方式布局
数据提供统一的入口。无论是在 MVP、MVC 还是 MVVM 中，提供一个统一的数据入口，都可以让代码变得更加易于维护。比如可使用一个DataManager，把 http、preference、eventpost、database 都放在DataManger里面进行操作，我们只需要与DataManger打交道
提取方法，去除重复代码。对于必要的工具类抽取也很重要，这在以后的项目中是可以重用的
尽可能的使用局部变量
尽量减少对变量的重复计算
-
尽量在合适的场合使用单例。使用单例可以减轻加载的负担，缩短加载的时间，提高加载效率。但并不是所有的地方都适用于单例，简单来说单例主要适用于以下三个方面：
- 控制资源的使用，通过线程同步来控制资源的并发访问。
- 控制实例的产生，以达到节约资源的目的。
- 控制数据的共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。
检测内存泄漏。可使用Instruments分析内存
尽量减少在代码中直接使用数字常量，而使用宏定义等方式。如：MAX_NUMBER_PHONE替代8等等。这样我们搜索也比较方便
尽量减少代码中的重复计算，比如代码中多处要使用屏幕宽度，然后计算：[[UIScreenmainScreen] bounds].size.width ,很多次，闲得很繁琐，代码也冗长。不如直接宏定义：
-
合理使用约定俗成的缩略词：
- 1 alloc分配
- 2 msg 消息
- 3 max 最大
- 4 nib Interface Builder
- 5 init 初始化等
合理范围内使用链式编程
if-else超过四层的时候，就要考虑重构，多层的if-else结构很难维护
当需要一定条件才执行某项操作时，最前面的应该是最重要的代码，不要将最重要的代码内嵌到if中，如良好的风格是：
if (! boolValue) {
return;
}
- 所有的逻辑块都使用{}花括号包围，就算只是一行代码
- 明确指定构造函数，并有适当的注释
- 不要在init方法中把变量或者说属性初始化为0或者nil，因为没有必要
- UIView的子类初始化的时候，不要进行任何的布局操作。布局操作应该在layoutSubviews里面做；需要重新布局的时候调用setNeedsLayout，而不要直接调用layoutSubviews
- 保持公共API简单，也就是保持.h文件简单。放在.h中声明的函数都是会被公开的，如果根本就没必要对其他类公开，再不要在.h中声明。OC中的方法都是公有方法，没有私有方法一说。
- 一个文件只实现一个类。同一个文件中不要有多个类
- Protocol单独用一个文件来创建，尽量不要与相关类混在一个文件中
- 在类定义中使用到自己定义类的时候，尽量不要在头文件中引入自己定义类的头文件，使用@class替代。而在实现文件中引入头文件。
- 布局时尽量使用相对布局，比如使用子View在父View中的相对位置
- 方法体中的第一行留空，最后一行不留空，这样一个方法就会比较清晰.但是如果该花括号里面又是一个if，for之类的带花括号的语句块，那么上述的第一行可以不留空。同样，如果花括号内第一行是注释的话，第一行也可以不留空。注释也起到了分隔代码的作用，看起来比较清晰。再者，如果花括号内只有一行代码，第一行可以不留空。
- block中第一行也要留空，同方法体中的第一行留空，使代码清晰
- 代表类方法和实例方法的"+"加号,"-"减号后需要一个空格
