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中第一行也要留空,同方法体中的第一行留空,使代码清晰
- 代表类方法和实例方法的"+"加号,"-"减号后需要一个空格