命名

Bundle id命名：

规则：采用反域名命名规则，全部使用小写字母。一级包名为com，二级包名根据应用进行命名。

类命名：

类命采取驼峰命名规则，即首字母必须大写，如果为词组，则每个单词的首字母必须大写，类名只能使用名词或名词词组；并以项目工程开头命名，力求类名简单 。

继承自UIView的类以View结尾。

继承自ViewController的类以ViewController 结尾。

保存数据的实体以Model结尾。

方法的命名：

规则：方法名第一个单词是一个动词，其首字母小写，其后的所有单词首字母大写。

如：- (void) addNotification{}

类中常用方法命名：

类的获取方法

如果返回值为单个值，一般在头部加上单词“get”。如果返回值是数组或列表，要在头部加单词“find”

如：- (NSString*)getUserName{}、- (NSArray*)findFriends{}

类的设置方法

在被访问字段名的前面加上前缀 set

如：- (void)setName:(NSString *)name{}

类的布尔型判断方法

一般要求方法名使用单词 is或has 做前缀

如：isNetWorkConnected（）

构造方法应该用递增的方式写。

参数个数少的在前

变量命名

规则：第一个单词首字母必须小写，往后的单词需要符合驼峰命名规则，即第一个字母大写。变量名尽可能的使用名词或名词词组。同样要求简单易懂，不允许出现无意义的单词。

如：String *userName

其他命名规则

实例变量命名

加前缀“_”

控件变量命名

规则：一般的变量命名后加上控件名称

IBOutlet UILabel *userNameLabel;

常量命名：

规则：必须全部大写，单词间用下划线隔开。

如：MAP_KEY

异常命名：

规则：自定义异常首字母大写，以 Exception 为结尾。

如：AppException

资源命名：

项目中所使用的所有资源命名必须以全部单词小写，单词间以下划线分割，加前缀区分。

原则：

1）采用单词全拼，或者大家公认无岐义的缩写(比如：nav，bg，btn等)

2）采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块主要包括统一的背景，导航条，标签，公共的按钮背景，公共的默认图等等；私有模块主要根据app的业务

功能模块划分，比如用户中心，消息中心等

btn_xx_normal          按钮正常情况下的效果

btn_xx_press             按钮点击下的效果 

bg_head                    背景图片使用bg_功能_说明

def_search_cell          默认图片使用def_功能_说明

icon_more_help         图标图片使用icon_功能_说明

seg_list_line              具有分割特征的图片使用seg_功能_说明

sel_ok                        选择图标使用sel_功能_说明

代码风格

整体代码风格需要统一

Import

Import语句引入的次序如下：

IOS imports

第三方库

自定义.h文件

在每组内部按字母排序，大写字母排在小写字母的前面。每个大组之间应该空一行。

空格

1. 关键字与其后的表达式之间需要加空格。

2. 单目操作符不应与操作数分开。

3. 除’,’外，其它双目操作符应与它们的操作数用空格隔开。

4. 在.h中协议<>前面有一个空格。

5. 在.h中成员声明时，类型与变量之间有至少1个空格。*号靠近变量，不靠近类型。

6. @property后留1个空格，（）里面，逗号紧跟前一变量，与后一变量之间留1 个空格。（）外面，先留1个空格，再声明属性。

7. 方法的+，-后面与（）。

8. 返回类型与*之间留1个空格，方法参数中返回类型与*之间留1个空格

9. 在多参数方法中，每个参数后面都有1个空格。

10. Switch..case 语句，代码块需要留4个空格。

11. If语句嵌套，内部if语句需要留4个空格。

.h文件空行

以下情况要空行：

1. 头文件包含(#import)与@class之间

2. @interface与@class之间

3. 头文件{}内，空1行开始写成员对象。

4. 头文件{}外，空1行开始写属性。

5. 属性与方法之间。

6. 如果需要声明protocol，空2行接着写。通常protocol写在@end后面，但是声明在@interface之前。

7. 方法与方法之间空1行。

8. 方法与@end之间。

.m文件空行

1. 文件说明与头文件包含(#import)之间。

2. 头文件包含(#import)之间。

3. @implementation和@synthesize之间。

4. @synthesize与方法之间。

5. 变量声明后需要空1行。

6. 各功能块之间。

7. #pragma mark 与方法之间。

Log

规则：统一使用自定的log服务，不直接使用系统自带。

语句

每行只能有一个语句

每行代码最多不得操作100个字符。

控制语句

If语句

判断中如果有常量，则应将常量放在判断式的右侧，如if (a > b)

如：if (index > 0) …… //单条语句,放在if同一行

if (index > 0){ //多行语句

……….

}

While语句

循环语句中不允许出现表达式。

如while（I < documents.getCount()）

尽可能保证.h文件的简介性，可以不公开的API就不要公开，写在实现文件中即可

注释

头文件注释：

所有的源文件都应该在开头有一个注释，其中列出头文件的相关描述、作者、以及对应的版本信息。

/*!

@header 头文件名称

@abstract 关于这个源代码文件的一些基本描述

@author作者

@version 1.00 2012/01/20 Creation (此文档的版本信息：版本号+创建时间)

*/

类注释

每一个类都要包含如下格式的注释，以说明当前类的功能等。

/*!

@class类名

@abstract 这里可以写关于这个类的一些描述。

*/

枚举注释

每一个枚举都需要包含相对应的enum描述，以及每个枚举值对应的含义。

/*!

@enum枚举名称

@abstract 关于这个enum的一些基本信息

@constant 各个对应值得含义，如： OKButton 对应的是OK按钮的Tag

*/

typedef NS_ENUM (NSInteger,RunGoalTypeE){

kRunGoalTypeNone= 0,//无目标

kRunGoalTypeTime= 1,//以时间为目标

kRunGoalTypeDistance= 2,//以距离为目标

kRunGoalTypeCalori= 3,//以消耗卡路里为目标

};

协议注释

协议需要注明是哪个类对应的protocol，以及自身的相关描述。

/*!

@protocol 协议名称

@abstract 这是哪个类的protocol

@discussion 具体描述信息

*/

方法注释

包括当前方法的用途，当前方法参数的含义，当前方法返回值的内容和对应的错误参照。

/*!

@method 方法名

@abstract该方法的一些简要描述

@discussion该方法的具体使用方式，需要注意的地方，如果你是设计一个抽象类或者一个共通类给给其他类继承的话，在这里需要具体描述一下怎样使用这个方法。

@param text参数列表

@param error 错误参照

@result 返回结果

*/

属性注释

/*!

@property 属性名称

@abstract 该Property的一些基本描述。

*/

类别注释

/*!

@category 类别名称

@abstract 哪个类的类别

*/

文件组织结构

1. 类文件组织

建议逻辑结构和物理结构保持一致，以便有效地管理文件

基于MVC设计模式原则，至少要保证controller与数据处理，网络请求相对独立

基于功能模块原则，功能模块分包括数据/网络处理，UI前端界面两部分，数据/网络处理应该在数据/网络处理的框架下，而UI前端界面比如用户中心，消息中心，它们的专有的controller，view等应该在属于文件夹。还会遇到一些公共的view，可以开辟出公共的文件夹来管理

在实际中使用中， 可以结合项目特点灵活使用，但基本的原则一定要保持，保持良好的类文件组织结构，对团队有益无害。

2. 图片资源文件组织

图片资源文件，强烈建议采用Images.xcassets管理，尽量少用自己创建的文件夹管理。

使用Images.xcassets的优势很多，具体可以查阅读相关文献资料，这里只从工程管理上说一点，在Images.xcassets中添加图片资源，不会对project文件造成改变，而直接在文件夹里添加图片文件，每次都会对project文件造成改变，因此使用Images.xcassets管理图片资源可以减少project冲突的次数。

2. 类代码组织

一个原则：析构函数- (void)dealloc最好放到类最上面，第一眼就可以看到这个方法，可以方便看到是否remove了。一些操作，对内存的合理释放等，controller，view的生命周期函数放到最上面，自己实现的方法在下面，相同/相近功能的方法采用#pragma mark -来标记，以便查看。

修改规范

新增代码行

新增代码行的前后应有注释行说明。

//修改人，修改时间，修改说明

新增代码行

//修改结束

删除代码行

删除代码向的前后用注释行说明

//修改人，修改时间，修改说明

要删除的代码行(将要删除的语句进行注释)

//修改结束

修改代码行

修改代码行以注释旧代码行后再新增代码行的方式进行。

//修改人，修改时间，修改说明

//修改前代码行开始

//修改前代码行

//修改前代码行结束

//修改后代码行开始

修改后代码行

//修改结束

避免出现的情况

永远不要有空的catch语句。替代方案：向方法的调用者抛出异常、或者抽象级别抛出新异常。

避免在一条语句中给多个变量赋相同的值

不要将赋值运算符用在与相等运算符混淆的地方

重复代码，复制-粘贴

长方法，将所有逻辑处理放在一个方法里面，每个方法都应有其自己的意图

大类，妄想将所有模块放在一个类中实现。

小类，一个类所承担的责任太少，应该将其消除，类的维护需要额外的开销