通过建立代码编写规范，形成iOS开发团队编码约定，提高程序的可靠性、可读性、一致性、可维护、可扩展，保证程序代码的质量。提高程序的重用性，使开发人员之间的工作成果可以共享。
参与整理：李朝阳
一、命名规则
官方规则：Cocoa代码指南
1、总则
- 简洁
简单明了，尽量使用全拼
应该： setBackgroundColor
不应该：setBkgdColor
当然，我们也会有一些常用的缩略词，比如 info 代表 Information等（待补充）
一致性
作用相同，或者在表达同一件事时，统一命名。
比如位置存储信息 location，不要再出来place表示位置的情况。无自引用
应该：nameString
不应该：nameStringObject
2、一般类、属性、方法命名
遵守驼峰命名法，类名首字母大写，方法名和属性首字母小写（首字母为缩略词，如WWDC时除外）
- 类名需要加前缀，前缀一般为：“项目关键词”+“模块关键词”
如短信需求，前缀应该为“MGSMS”（现在是FB，因为之前项目名为5Ber）
以类型为结尾，如:
MWBaseViewController、MWOrderListCell、MWSuggestTextView...
- 方法命名：参数前要加描述词
应该：- (void)updateListData:(NSDictionary *)data;
不应该：- (void)update:(NSDictionary *)data;
- 私有变量应该尽可能代替实例变量的使用。尽管使用实例变量是一种有效的方式，但更偏向于使用属性来保持代码一致性。
属性get忽略 is前缀，建议如下写法：
@property (assign, getter=isEditable) BOOL editable;
3、枚举命名规则
枚举名同类名规则，加前缀，大驼峰命名
枚举值去掉前缀，大驼峰命名
typedef NS_ENUM(NSInteger, FBSMSControllerSelectType) {
ControllerSelectTypeOne,
ControllerSelectType..,
};
多用枚举控制多态，减少bool值等去判断的情况，增加可读性
4、常量命名规则
- 以const修饰一个常量，一般是写在.h文件中，然后将.h的头文件加入预编译pch文件中，以小写字母k开头，后面单词遵循"驼峰原则"命名。例如:
const float kMaxHeigh = 100.f;
const int kNumberCount = 100;
- 如果是特殊含义的常量，声明形式为"各APP前缀+名称"，形式如下:
const NSString *FB*** = @"xx"
宏定义
宏定义在很多方面都会使用，例如定义高度、工具类，还有诸如文件路径。宏定义的命名，需要传参数的时候使用前缀，比如"FB":
#define FB***
二、代码格式化
- 文件夹规范
Mogo
- Main：主流程页面代码
- Home:
- subModule
Controller
server
- Model
- View
- iVoice:
- ...
- Common：通用代码(自己封装的一些UI库之类的)
- Customer
- Tool
- FBAnalytics
...
- Vender：拉进来的代码库
- Resource:资源文件
- Other：全局文件
Products：应用程序
Pods：pod管理
Frameworks：手动拉入的代码库
- 常用规范
- 运算符前后前后各一个空格
- *号紧贴属性名，和类名之间隔一个空格
NSString *text = @"hello world";
- 括号前后各一个空格
- 属性修饰符和前面的,隔一个空格
@property (nonatomic, strong) UITableView *tableView;
- 当参数过长的时候，没个参数占用一行，且按照冒号对齐。
- 在声明类方法或者实例方法的时候，“+”或者“-”和返回值之间保留一个空格，
且返回值和方法名的第一个字母之间不要留空格。
-(void)doSomethingWithName:(NSString *)name
rect:(CGRect)rect;
- 注释一般放在.h，.m文件尽量减少注释
单行的用//+空格开头，多行的采用/* */注释
//TODO: 用来注释没有完成的功能
#warning 用来标记自己的debug修改，以免遗漏
哪里需要注释:
1. 在某个变量、属性、或者方法不能够直接从名字得知其用途时。
2. 区分代码区时(在常量文件和控制器类的.h文件和.m文件里)。
3. 在不相关的业务处理交叉点。
4. 文件的基本信息
5. 有疑惑的地方(FIXME)
6. 未完成或者待优化的地方。(#waring //TODO:)
7. 声明枚举时应该对每个值说明。
8. 修改别人代码的时候。
9. 编写API时，一般需要对所有的接口和属性带上注释
注释需要注意:
1. 不要为了注释而注释，请只在关键点注释
2. 划分代码块最好的方式不一定是注释，有时候使用空行也可以达到很好的效果。
- 初始化
在初始化方法中，不要将变量初始化为“0”或“nil”，那是多余的，
内存中所有的新创建的对象(isa除外)都是0，所以不需要重复初始化 为 “0”或“nil”;
对nil的检查
仅在有业务逻辑需求时检查nil,而非为了防止崩溃。
- 组件的创建，应该使用代码块或者懒加载的方式（我习惯用代码块）
- 建议项目统一使用Masonry的方式布局。不允许出现直接设置frame的情况。
xib的使用，尽量减少拉约束的情况
- controller代码结构
#pragma mark lifeCycle
- (instancetype)init {}
- (void)viewDidLoad {}
- (void)viewWillAppear:(BOOL)animated {}
- (void)dealloc {}
- (void)didReceiveMemoryWarning {}
#pragma mark public-method
#pragma mark private-method
#pragma mark event-response
#pragma mark - Protocol conformance
#pragma mark - UITextFieldDelegate
#pragma mark - UITableViewDataSource
#pragma mark - UITableViewDelegate
#pragma mark set/get
- (NSMutableArray *)dataSectionArr{}
- 排版格式
- 尽量使用.语法
应该：array.count
不应该：[array count]
多使用黄金路径
- (void)someMethod {
if(error) {
return;
}
doSomething
}
而不是：
- (void)someMethod {
if(!error) {
doSomething
}
}
多使用三目运算符：
result = a > b ? x : y;
三、git版本控制
1、分支管理
- 只允许从dev分支拉出新的分支
- 其他分支只和dev分支做合并
- 提交代码时，确保本地build success
- 项目测试结束之后，即定档之后，才合并到master分支
- 项目提测需要打tag
2、项目内环境配置（APPInfo管理）
三种项目渠道，主要是为了在统计和crash收集时作区分，以便更好地定位
- fir：即平时我们打包到fir的环境，测试证书，release环境
- beta:testflight版本，正式证书，release环境
- appstore:testflight版本，正式证书，release环境
APPIsDev()：当且仅当域名为"ifreeapi.ifreegroup.co"返回false
其他
1、尽量减少IO的操作，优先使用内存保存
不要出现存储传值的情况
2、数据量较大的操作，放到子线程处理
3、数据处理从代码中抽离出来，我一般的习惯是一个控制器一个server，数据处理放到server中
4、如何封装代码？？
分享总结
MOGO项目中亟需解决的问题：
1、类名命名，添加前缀 "FB"+"模块名"
2、减少不必要的注释，命名尽量见名知意
3、xib使用限制：不建议使用，或者只在简单的静态view使用
4、frame使用限制：优先使用autolayout，禁止类似frame.size.width这样的更新布局的做法
5、项目文件夹的规范
6、数据转model的规范（从data层开始转换）
有争议的点：
1、frame的使用场景
2、注释的场景
需要完善的点：
1、代码封装
2、数据统一管理
下次分享：
日期：8.23
分享者：浩滨
主题：蓝牙的原理及在iOS的使用