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开发人员共同代码规范，共同维护开发，
如有更好的建议，欢迎在此基础上进行修改并在版本历史记录中添加修改内容,谢谢