IOS设备尺寸、设计尺寸及编码规范

参考

屏幕尺寸
设计尺寸规范
编码规范

编码规范

命名规范

• 小驼峰原则：第一个单词首字母小写，其余都大写。例如：userName

项目命名

• 项目命名尊享大驼峰原则。例如：HuiBoProject

Bundle Identifier 命名

• Bundle Identifier：采用反域名命名规范，全部采用小写字母，以域名后缀+公司顶级域名+应用名形式命名，例如：com.company.huiboproject

类名

• 类的命名都遵循大驼峰命名。一般是：前缀 + 功能 + 类型。例如：HB + Login + ViewController

• 常用控件命名类型

• 其它类

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遵循实际规则即可。或者一看就知道的通用简写）
  方法命名对照表（方法多为动词或动名词）

• 函数调用时所有参数在同一行。如果参数过多，则可以每行一个参数，每个参数以冒号对齐
• 任意函数长度不得超过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打交道

• 提取方法，去除重复代码。对于必要的工具类抽取也很重要，这在以后的项目中是可以重用的

• 尽可能的使用局部变量

• 尽量减少对变量的重复计算

• 尽量在合适的场合使用单例。使用单例可以减轻加载的负担，缩短加载的时间，提高加载效率。但并不是所有的地方都适用于单例，简单来说单例主要适用于以下三个方面：

  1. 控制资源的使用，通过线程同步来控制资源的并发访问。
  2. 控制实例的产生，以达到节约资源的目的。
  3. 控制数据的共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。

• 检测内存泄漏。可使用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中第一行也要留空，同方法体中的第一行留空，使代码清晰
• 代表类方法和实例方法的"+"加号,"-"减号后需要一个空格