代码规范

通过建立代码编写规范，形成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<CyTableViewCellModel *> *)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()：

其他

1、尽量减少IO的操作，优先使用内存保存
不要出现存储传值的情况
2、数据量较大的操作，放到子线程处理
3、数据处理从代码中抽离出来，我一般的习惯是一个控制器一个server，数据处理放到server中
4、如何封装代码？？