一、命名
驼峰法 分小驼峰法和大驼峰法。
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 -” 与下面的代码之前不要空行