前言
遵守规范也是让代码更清晰明了，易读，易用，易维护，可以更好的适应团队开发。自己看着也是赏心悦目，何乐而不为呢。
1.基本准则
1.1编写清晰
简单明了的命名最好，不要用单词的简写，尽量用单词的全称。可以看看苹果的API格式，仿照苹果的命名，尽量用英文，而不是拼音。
1.2一致性
比如方法名的功能类型的一致性，比如获取某些数据 - (NSString *)getName，- (NSString *)getAge 中的get；或者设置数据 - (void)setName，- (void)setAge 中的set。统一方法名可以让人一看这方法就知道是干什么用的，提升开发效率。
1.3驼峰原则
- 大驼峰原则：每个单词的首字母大写(UserNameTextField)
- 小驼峰原则：第一个单词首字母小写，其余都大写(userNameTextField)
2.命名规范
2.1类命名
类的命名是采用大驼峰原则，如
UserLoginViewController
在实际开发中，一般会在类名前面加个前缀：
OYUserLoginViewController
加统一前缀方法如下图：
设置完后，每次在创建类的时候会自动添加前缀。
User → 用户
Login → 登陆
ViewController → 控制器
这个类的用途就一目了然了
其他例子：OYUserModel，OYTitleView，OYNetManager。。。
应用级别的类名（需要在其他项目中用到的类），可以不使用前缀或者使用自定义前缀
即为：PhotoBrowser或者XXPhotoBrowser
2.2分类命名
UIView+OYFrame 或者 UIView+OYExtension
前者是对UIView这个类做的扩展，OY是前缀，Frame算是具体化功能，对Frame获取。比较清晰。
后者也是对UIView这个类扩展，但是并没有写明具体功能，可以在里面添加关于UIView的很多扩展。具体功能可以在.h文件里注释。文件较少易于管理。
二者的选择看个人喜好了
2.3方法命名
方法的命名是采用小驼峰的原则，如
- (XXModel *)modelWithDictionary:(NSDictionary *)dictionary;
此类命名可以模仿苹果提供的API，看见方法名大概可以猜出开是做什么的。注意参数名也是小驼峰式的。
代理方法仿照苹果API。
2.4变量命名
普通变量采用小驼峰原则，
NSInteger userCode;
成员变量要在前面需要加下划线'_'
@interface ViewController () {
NSString *_sex;
NSString *_birthday;
NSInteger _nameCount;
}
全局变量我一般在末尾加个下划线'_'
NSInteger userCode_;
2.5常量命名
常量(宏、枚举、全局常量、局部常量等)
1. k + 大驼峰 kUserCode
2. 前缀 + 大驼峰 OYUserCode
3. 单词大写加'_' USER_CODE
枚举：下面是个我写的启动页广告点击事件的枚举，可以参考下
typedef NS_ENUM(NSInteger, OYLaunchImageAdViewActionType) {
OYLaunchImageAdViewActionTypeAd, //点击广告
OYLaunchImageAdViewActionTypeSkip, //点击跳过广告
OYLaunchImageAdViewActionTypeTimerOver, //广告定时器结束
};
2.6文件夹命名
创建文件夹最好创建实体文件夹，找到工程目录，创建相应文件夹并拖入工程。
文件夹命名使用相应模块的英文，首字母要大写。
分享下Xcode8的两个注释快捷键
- command + / 所选行会被注释掉
- command + option + / 在方法名或变量名的所在行或上一行使用，会自动填充注释段，可输入方法参数的意思或者作用。
3.编码规范
- 删除多余的空行
1.1 所有的方法之间空一行
1.2 所有的代码块之间空一行 - 删除多余的注释
2.1 删除不用的代码
2.2 删除没有意义的注释 - 删除多余的方法
3.1 如果有方法一直不会用到，请删除（除工具类）
3.2 没有执行任何业务逻辑的方法，请删除或给予注释 - 删除多余的资源或文件
- 添加必要的注释
5.1 所有 .h 文件中的property 需要给出清晰注释，非必要变量请勿防止出现在 .h文件中
5.2 比较大的代码块需要给出注释
5.3 所有自定义的方法需要给出注释
5.4 所有代码中出现的阿拉伯数字需要给出注释
5.5 程序中出现加密／解密 逻辑的操作地方，需要给出注释说明过程（无论是系统还是自定义） - 尽量少用大段打印，非必要可以注释或删除，尽量消除警告（不影响程序正常运行）
- 整体代码风格要统一
7.1 代码后的'{'不需要独占一行
7.2 运算逻辑符和变量之间空一格
7.3 多用#pragma mark - xxx讲方法分块，#pragma mark与下面的代码之前不要空行
7.4 遵循一般代码规范，多模仿苹果API
4.通用规范
1 下面所有规则对第三方类库无约束
* 所有类、方法、属性等命名，做到见名知意，采用驼峰式命名规则
* 根据资源类型或者所属业务逻辑对项目资源进行分组，使得整个项目结构清晰明了
* 整个项目保持一种代码书写风格（这个风格由无锡团队根据自己编码习惯来定），让你的代码变的优雅！
2. 命名规范
* 所有类名称以项目工程开头命名，eg：“XP”、“ZJG”、“SZ”
* 针对不同视图控制器，在末尾添加后缀，eg：
UIViewController 后缀添加“ViewController”
UIView 后缀添加“View”
UIButton 后缀添加“Button”、“Btn”
UILabel 后缀添加“Label"
3. 单页代码最好控制在800行以内，每个方法最好不要超过100行，过多建议对代码进行重构
4. 相同的逻辑方法定义避免在多个地方出现，尽量将公用的类、方法抽取出来
5. 删除未被使用的代码，不要大片注释未被使用的代码，确定代码不会使用，请及时删除
6. 对其他项目中copy过来的代码，根据具体需要更新代码风格，及时删除未被使用的代码
7. 项目中所有Group或者文件名称（图片名字等），不要使用汉字命名，尽量使用英文命名，国内特有名词可以使用拼音。
8. 项目中所有Group都需要在项目目录中存在一个真实的目录，Group中的文件与真实目录中文件一一对应。
9. 请在项目中写必要代码的注释
10. 请多使用 #pragma mark - Mark Name 对方法进行分组 eg:
* #pragma mark - View lifeCycle
* #pragma mark - View lifeTerm
* #pragma mark - Init methods
* #pragma mark - Action methods
* #pragma mark - Common methods
* #pragma mark - UIActionSheetDelegate
* #pragma mark - UIImagePickerControllerDelegate
* #pragma mark - UITableViewDelegate Methods
* #pragma mark - UITableViewDataSource Methods
* #pragma mark - UIScrollViewDelegate Methods
* #pragma mark - UITextFieldDelegate Methods
* #pragma mark - UITextViewDelegate Methods
