命名规范
文件命名
原则:采取驼峰命名规则,即首字母必须大写,如果为词组,则每个单词的首字母必须大写,类名只能使用名词或名词词组。
- 所有类名以
MG
(米果的缩写)开头; - 根据功能模块,类添加功能模块前缀,如个人中心模块,类加MGUC前缀;
- 继承自
UIView
,UITableViewCell
,UIButton
等以View
,Cell
,Button
结尾; - 继承自
ViewController
的类以Controller
结尾; - 继承自
TableViewController
的类以TableController
结尾; - protocol定义时,前缀以
MG
开头,后缀以Delegate
结尾; - Category命名,类名+标识+扩展,如
UIImageView +HP+Web
,命名为UIImageView+HPWeb
; - 数据模型以Model结尾;
变量和对象命名
原则:变量名使用小驼峰法, 使变量名尽量可以推测其用途属性具有描述性,每个属性命名都加上类型后缀。
- 类成员变量名,遵守小驼峰法命名并前缀下划线
_
。如UIButton *_submitButton
; - 局部变量名,遵守小驼峰命名规则。如
UIButton *submitButton
; - 通知相关变量名,添加
Notification
为后缀; - 控件类型变量,命名需添加相应类型结尾;
- 变量名需有特定的意义,建议修饰+类型
- const常量,以小写k开头,后面单词首字母大写,其余小写。如:
const float kMaxHeigt = 100.0f
;
枚举命名
原则:遵循大驼峰命名法,如:
typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {
UIViewAnimationTransitionNone,
UIViewAnimationTransitionFlipFromLeft,
UIViewAnimationTransitionFlipFromRight,
UIViewAnimationTransitionCurlUp,
UIViewAnimationTransitionCurlDown,
};
方法命名
原则:遵守小驼峰原则,首字母小写,其他单词首字母大写,每个空格分割的名称以动词开头。
A 代理方法
- 以发送代理的对象类名作为代理方法名的开始(去掉类名的前缀,并且小写开头)
B 实例方法
- 执行性的方法应该以动词开头,小写字母开头;
- 返回性方法,若返回值为单个值,在头部加上单词
get
; - 返回性的方法应该以返回的内容开头,但之前不要加get;
资源命名
原则:“模块+功能”命名法
- 可使用公认无歧义的缩写,如:
background
对应bg
,viewcontroller
对应vc
,button
对应btn
,navgation
对应nav
; - 模块分为公共模块、私有模块:公共模块主要包括统一的背景,导航条,标签,公共的按钮背景,公共的默认图等等;私有模块主要根据app的业务功能模块划分,比如用户中心,消息中心等。
- 如用户中心用户头像图片的命名可以为:uc_imageview_user_icon
编码规范
原则:可复用, 易维护, 可扩展.
注释
- 变量注释应详细描述变量用处(文档注释)
- 枚举注释应详细描述枚举和每一个元素用处(文档注释)
- 方法注释应详细描述方法作用、参数意义、返回值意义(文档注释)
- 其他使用单行注释
资源文件
- 资源文件全部放入
Supporting Files
文件夹下 - app支持iOS8及以上,图片资源放入
Assert.xcassets
,可根据功能模块分类或资源分类建立自己的Folder - app支持iOS7及以上,图片资源放入
Resources
文件夹,各个资源按照功能模块或资源分类放在相应的文件夹内
设计模式
原则:项目分层:http://o9zrwgllm.bkt.clouddn.com/%E6%9E%B6%E6%9E%84%E7%A4%BA%E6%84%8F%E5%9B%BE.png
- 单个模块使用MVC,或MVVM
- 对于可重复使用的模块,应抽离为单独工具模块,留好清晰的入口及出口
- 建立领域(业务)模型,解耦图形界面,数据存储和业务逻辑
- 抽离较独立的功能,抽离对应的service
单元测试
原则:使用Apple自带的XCTest框架进行单元测试
- 对于接口和可进行模块化测试的部分,应编写对应的单元测试,测试包含边界条件测试,非法条件测试,性能测试等
第三方库管理
- 对于引入的第三方库,统一使用cocoapods进行管理
- 若第三方库需要修改调用效果,尽可能使用Category或子类重写调用效果
版本管理
- 使用git进行版本管理
- 提交log,最好清晰表述相关的功能修改,若修改bug,最好加上bug编号
- 发布的大版本,打tag标示对应的版本,tag名称规则为
正式版版本_日期
,如5_5_20160715
注意:
- 注意变量的强弱引用
- 注意block等循环引用问题
- 注意解耦UI,数据,业务逻辑
- 注意各种费时操作尽可能不阻塞主线程