iOS开发 规范个人总结

一、命名

驼峰法 分小驼峰法和大驼峰法。

1.基本原则

1.1 要求

又清晰又简洁。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。

API的名称不要有歧义，一看API就知道是以什么方式做了什么事情，不要让人有疑问

1.2 一致性

做某个事情代码通常都叫这个名字，比如tag、setStringValue。在不确定怎么起名字的时候，可

以参考一些常用的名字：Method Arguments

2. 类命名

类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。类名中应该包含一个或多个名词来

说明这个类（或者类的对象）是做什么的。

在应用级别的代码里，尽量不要使用带前缀的类名。每个类都有相同的前缀不能提高可读性。不

过如果是编写多个应用间的共享代码，前缀就是可接受并推荐的做法了(型如

YNPhotoBrowser)。

示例1：

@interface ImageBrowseView :UIView

@end

示例2：（带前缀YN）

@interface YNPhotoBrowser :UIView

@end

3. 类别命名

类名+标识+扩展（UIImageView +HP+Web）

例：如果想要创建一个基于UIImageView 的类别用于网络请求图片，应该把类别

放到名字是UIImageView+YNWeb.h的文件里。UIImageView为要扩展的类名，YN为专属标

识，Web为扩展的功能。

类别的方法应该都使用一个前缀(型如yn_myCategoryMethodOnAString),以防止Objective-

C代码在单名空间里冲突。

类别YNWeb头文件，UIImageView+YNWeb.h如下：

@interface UIImageView (YNWeb)

- (void)yn_setImageWithURLString:(NSString *)urlStr;

@end

4. 方法命名

方法使用小驼峰法命名, 读起来应该像一句完整的话，读过之后便知函数的作用。执行性的方法

应该以动词开头，小写字母开头，返回性的方法应该以返回的内容开头，但之前不要加get。

示例：

- (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;

如果有参数，函数名应该作为第一个参数的提示信息，若有多个参数，在参数前也应该有

提示信息, 一些经典的操作应该使用约定的动词，如initWith,insert,remove,replace,add等等。

5. 变量命名

变量名使用小驼峰法, 使变量名尽量可以推测其用途属性具有描述性。让代码可以迅速被理解。

5.1 类成员变量：

成员变量用小驼峰法命名

示例：

@interface ViewController ()

@property (nonatomic, strong)NSMutableArray*dataArray;

@property (nonatomic, strong)UITableView*tableView;

@end

5.2 一般变量命名

示例：

NSMutableArray*ticketsArray=[NSMutableArrayarray];

NSInteger numCompletedConnections=3;

5.3 常量命名

常量(预定义，枚举)使用全大写，或者大驼峰（以实际情况为主）

示例：

typedef enum : NSUInteger

{

TEST_INIT = 1,

TEST_FULL,

TEST_GENDER_GENERATION,

} TEST_TYPE;

#define YNAPI_ERROR_CODE_OPERATE_ERROR-3001

局部常量使用驼峰法

static NSString *const reuseIdentifier = @“row";

6. 图片资源文件命名 （截图示例）

原则

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

2）采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块主要包括统一的背

景，导航条，标签，公共的按钮背景，公共的默认图等等；私有模块主要根据app的业务

功能模块划分，比如用户中心，消息中心等建议背景图采用以bg作前缀，按钮背景采用btn作前

缀

二、文件组织结构

1. 类文件组织

iOS工程文件结构分物理结构和逻辑结构，建议逻辑结构和物理结构保持一致，以便方便有

效地管理

类文件。类文件组织要遵循以下两大原则：

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

基于功能模块原则，功能模块分包括数据/网络处理，UI前端界面两部分，数据/网络处理应

该在数据/网络处理的框架下，而UI前端界面比如用户中心，消息中心，它们的专有的

controller，view等应该在属于文件夹。还会遇到一些公共的view，可以开辟出公共的文件夹

来管理

2. 图片资源文件组织

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

总结

单页代码最好控制在600行以内，每个方法最好不要超过100行，过多建议对代码进行重构

2.相同的逻辑方法定义避免在多个地方出现，尽量将公用的类、方法抽取出来

3.删除未被使用的代码，不要大片注释未被使用的代码，确定代码不会使用，请及时删除

4.对其他项目中copy过来的代码，根据具体需要更新代码风格，及时删除未被使用的代码

5.项目中所有Group或者文件名称（图片名字等），不要使用汉字命名，尽量使用英文命名。

6. 项目中所有Group都需要在项目目录中存在一个真实的目录，Group中的文件与真实目录中文件一

一对应。

7. 请多使用 #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

8. 删除多余的空行

* 所有方法与方法之间空1行

* 所有代码块之间空1行

9. 删除多余的注释

* 删除注释掉的代码

* 删除没有意义的注释

10. 删除多余的方法

* 如果方法没有使用到，请删除它

* 如果方法没有执行任何业务逻辑，请删除它或者给出一定注释

11. 删除未被使用的资源文件

12. 添加必要的注释

* 所有 .h 文件中的property 需要给出注释

* 所有自定义的方法需要给出注释

* 比较大的代码块需要给出注释

* 程序中出现加密／解密 逻辑的操作地方，需要给出注释说明过程（无论是系统还是自定义）

13. 整体代码风格需要统一

* 代码后面的”{“ 不需要单独占用一行 （示例：）

* 逻辑运算符 与 代码之前空一格 （示例：）

* “#pragma mark -” 与下面的代码之前不要空行