1. 前言：
命名规则对于维护代码来说是非常重要的,Objective-C方法名往往很长，不过这也有好处，可以更清晰地理解和直观理解方法，甚至无须过多的注释；
1.基本原则
1.0：代码清晰
又清晰又简洁的代码当然是最好的了，但简洁不如清晰重要。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。API的名称不要有歧义，一看你的API就知道是以什么方式做了什么事情，不要让人有疑问！
1.1：一致性
代码保持一致，例如：创建UI相关的方法,可以使用统一的方法命名，所见即所得，见表知其意，这样，既保证了代码的一致性，也可以方便我们后续维护和管理，也利于团队代码风格的一致，协调！
2.类命名
2.1：命名规范
小驼峰命名法：第一个单字以小写字母开始；第二个单字的首字母大写，如：testClass
大驼峰命名法：每一个单字的首字母都采用大写字母，如：
TestClass
类命名：
首字母大写，之后每个单词首字母都大写
使用能够反映类功能的名词短语
文件和类同名
举例：BaseClient .h、ImageStore .h
特殊类命名
如果是视图控制器的子类应添加后缀“ViewController”或者“Controller”
如果是视图的子类应添加后缀“View”
如果是按钮的子类应添加后缀“Button”
等……
举例：SettingsViewController、NavigationView
分类（类别）命名
与类命名相同，此外需添加要扩展的类名和“+”
举例：NSString+URLEncoding
协议（委托）命名
与类命名相同，此外需添加“Delegate”后缀
举例：ReplyViewDelegate
方法命名
首字母小写，之后每个单词首字母都大写
方法名使用动词短语
举例：- (void)setPostValue:(int)value
方法参数命名
首字母小写，之后每个单词首字母都大写
具有足够的说明性
不需要添加类型前缀
举例：- (void)sendUserInfo:(NSDictionary *)userInfo
常量
常量（宏定义，局部常量等）使用小写k开头的驼峰法
举例：kInvalidHandle , kWritePerm
枚举类型命名首字母大写，之后每个单词首字母都大写，最后加“s”
枚举变量使用枚举类型去掉“s”作为前缀，每个单词首字母大写，中间不允许加下划线
举例：typedef enum UIControlEvents{
UIControlEventTouchDown,
UIControlEventTouchUpInside
}UIControlEvents;
分组命名
使用英文，首字母大写，之后每个单词首字母都大写
每个分组使用模块的名字
使用的开源库统一放在“Library”分组下
使用的公共组件统一放在“Common”分组下
视图控制器及AppDelegate统一放在“Controllers”分组下
2.2：类注释规范
一.类的声明：
/** 类信息。此注释用在类声明的开头。
@class
@abstract 这里可以写关于这个类的一些描述。
*/
示例1：
/** 类信息。此注释用在类声明的开头。
@TestClass
@这是一个测试类
*/
@interface TestClass :UIView
@end
二：变量的声明
/**
@property property的相关注释。
@abstract 这里可以写关于这个Property的一些基本描述。
*/
示例2：
/**
* name:这是一个名字；
*/
@property (nonatomic,copy) NSString * name;
三：方法的声明
/**
@method 函数(方法)的相关注释。
@abstract 这里可以写一些关于这个方法的一些简要描述
@discussion 这里可以具体写写这个方法如何使用，注意点之类的。
如果你是设计一个抽象类或者一个共通类给给其他类继承的话，建议在这里具体描述一下怎样使用这个方法。
@param text 文字(这里把这个方法需要的参数列出来)
@param error 错误参照
@result 返回结果
*/
示例3：
/**
* 这是个请求数据方法；
* result : (NSObject*) 数据返回结果；
* block :( doBlock)block 代码块，返回结果需要完成的事；
*/
-(void)doRequestResult:(NSObject*)result andSuccessBlock:(doBlock)block ;
2.3：书写规范
文件都包含文件头，要说明文件名、作者、创建时间、变更记录
多人协作完成项目时，public接口的每个方法都应该添加关于函数，参数，返回值以及副作用的注释
当if语句的判断条件复杂时，需要用注释说明判断内容
接口类（继承于BaseController）的头文件每个方法前都应该注明方法的作用
3.文件组织结构
3.1:类文件组织
iOS工程文件结构分物理结构和逻辑结构，建议逻辑结构和物理结构保持一致，以便方便有效地管理类文件。
类文件组织要遵循以下两大原则：
基于MVC设计模式原则，至少要保证controller与数据处理，网络请求相对独立
基于功能模块原则，功能模块分包括数据/网络处理，UI前端界面两部分，数据/网络处理应该在数据/网络处理的框架下，
而UI前端界面比如用户中心，消息中心，它们的专有的controller，view等应该在属于文件夹。
还会遇到一些公共的view，可以开辟出公共的文件夹来管理。
在实际中使用中，项目实际负责人可以结合项目特点灵活使用，
但基本的原则一定要保持，保持良好的类文件组织结构，对团队有益无害。
3.2：图片资源文件组织
图片资源文件，强烈建议采用Images.xcassets管理，
尽量少用自己创建的文件夹管理。
使用Images.xcassets的优势很多，具体可以查阅读相关文献资料，这里只从工程管理上说一点，在Images.xcassets中添加图片资源，
不会对project文件造成改变，而直接在文件夹里添加图片文件，每次都会对project文件造成改变，
因此使用Images.xcassets管理图片资源可以减少project冲突的次数
3.3：类代码组织原则
一个原则：
1.析构函数-
(void)dealloc最好放到类最上面，第一眼就可以看到这个方法，
可以方便看到是否remove了一些操作，对内存的合理释放等。
2.controller，view的生命周期函数放到最上面
3.自己实现的方法在下面，相同/相近功能的方法采用#pragma
mark -来标记，以便查看。
4. iOS代码规范
4.1:团队规范
说明：一个好的团队，理所当然有其严格的代码规范，好的代码不仅可以提高团队的开放效率，也更利于团队项目的后期维护，统一的代码风格，也是团队的核心，所以规范代码很有必要！
**
1 删除多余的空行
所有方法与方法之间空1行
所有代码块之间空1行
2 删除多余的注释
删除注释掉的代码
删除没有意义的注释
3 删除多余的方法
如果方法没有使用到，请删除它
如果方法没有执行任何业务逻辑，请删除它或者给出一定注释
4 删除未被使用的资源文件
5 添加必要的注释
所有.h 文件中的property 需要给出注释
所有自定义的方法需要给出注释
比较大的代码块需要给出注释
所有代码中出现的阿拉伯数字需要给出注释
程序中出现加密／解密 逻辑的操作地方，需要给出注释说明过程（无论是系统还是自定义）
6 整体代码风格需要统一
代码后面的”{“
不需要单独占用一行
逻辑运算符 与 代码之前空一格
“#pragma mark -” 与下面的代码之前不要空行
遵循一般性的代码规范
4.2 iOS通用规范
1 下面所有规则对第三方类库无约束
* 所有类、方法、属性等命名，做到见名知意，采用驼峰式命名规则* 根据资源类型或者所属业务逻辑对项目资源进行分组，使得整个项目结构清晰明了
* 整个项目保持一种代码书写风格（这个风格由团队根据自己编码习惯来定），让你的代码变的优雅！
2. 命名规范
* 所有类名称以项目工程开头命名，：“QMX”、“SX”、“CS”,”PF”等···；
* 针对不同视图控制器，在末尾添加后缀，
* UIViewController 后缀添加“ViewController”
* UIView 后缀添加“View”
* UIButton 后缀添加“Button"
* UILabel 后缀添加“Label"
3. 单页代码最好控制在800行以内，每个方法最好不要超过100行，过多建议对代码进行重构
4. 相同的逻辑方法定义避免在多个地方出现，尽量将公用的类、方法抽取出来
5. 删除未被使用的代码，不要大片注释未被使用的代码，确定代码不会使用，请及时删除
6. 对其他项目中copy过来的代码，根据具体需要更新代码风格，及时删除未被使用的代码
7. 项目中所有Group或者文件名称（图片名字等），不要使用汉字命名，尽量使用英文命名，国内特有名词可以使用拼音。
8. 项目中所有Group都需要在项目目录中存在一个真实的目录，Group中的文件与真实目录中文件一一对应。
9. 请在项目中写必要代码的注释
10. 请多使用 #pragma
mark - Mark Name 对方法进行分组
5.版权声明
该规范为iOS开发人员共同代码规范，共同维护开发，
如有更好的建议，欢迎在此基础上进行修改并在版本历史记录中添加修改内容,谢谢
