(转)ios 代码规范

转自http://blog.csdn.net/pjk1129/article/details/45146955

引子

在看下面之前,大家自我检测一下自己写的代码是否规范,代码风格是否过于迥异阅读困难?可以相互阅读同伴的代码,是否存在阅读障碍?

若存在晦涩难懂的,理解成本增大的代码,说明你的团队需要自省了。

下面总结一下OC编程中的一些代码规范(苹果官方推荐的)。以OC为示例,但不局限于OC,也可以被当作别的编程语言的开发规范约定(仅需要把OC特有的东西按照你所使用的语言的惯例即可)

参考资料:苹果代码规范 对建议的代码规范的说明

命名

命名规则对于维护代码来说是非常重要的,。Objective-C方法名往往很长,不过这也有好处,让很多注释变得毫无意义。

本文推荐驼峰法,也是Objective-C社区的标准。

驼峰法分小驼峰法和大驼峰法。小驼峰法:除第一个单词之外,其他单词首字母大写。大驼峰法相比小驼峰法,大驼峰法把第一个单词的首字母也大写了。

1.基本原则

1.1 清晰

又清晰又简洁是最好的了,但简洁不如清晰重要。总的讲不要使用单词的简写,除了非常常用的简写以外,尽量使用单词全称。API的名称不要有歧义,一看你的API就知道是以什么方式做了什么事情,不要让人有疑问

1.2 一致性

做某个事情代码通常都叫这个名字,比如tag、setStringValue,那么你也这么叫。你在不确定怎么起名字的时候,可以参考一些常用的名字:Method Arguments

2. 类命名

类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。类名中应该包含一个或多个名词来说明这个类(或者类的对象)是做什么的。

在应用级别的代码里,尽量不要使用带前缀的类名。每个类都有相同的前缀不能提高可读性。不过如果是编写多个应用间的共享代码,前缀就是可接受并推荐的做法了(型如 JKPhotoBrowser )。

示例1:

@interface ImageBrowseView :UIView

@end

示例2:(带前缀JK)

@interface JKPhotoBrowser :UIView

@end

3. 类别命名

类名+标识+扩展(UIImageView +HP+Web)

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

放到名字是UIImageView+HPWeb.h的文件里。UIImageView为要扩展的类名,HP为专属标

识,Web为扩展的功能。

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

C代码在单名空间里冲突。如果代码本来就不考虑共享或在不同的地址空间(address-

space),方法命名规则就没必要恪守了。

类别HPWeb头文件,UIImageView+HPWeb.h如下:

@interface UIImageView (HPWeb)

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

@end

4. 方法命名 

方法使用小驼峰法命名, 一个规范的方法读起来应该像一句完整的话,读过之后便知函数

的作用。执行性的方法应该以动词开头,小写字母开头,返回性的方法应该以返回的内容

开头,但之前不要加get。

示例:

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

(instancetype)arrayWithArray:(NSArray *)array;

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

提示信息(一般不必加and)

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

5. 变量命名 

变量名使用小驼峰法, 使变量名尽量可以推测其用途属性具有描述性。别一心想着少打几

个字母,让你的代码可以迅速被理解更加重要。

5.1 类成员变量:

成员变量用小驼峰法命名并前缀下划线,Objective-C 2.0,@property 和 @synthesize 提供

了遵守命名规范的解决方法

示例:

@interface ViewController ()

@property (nonatomic,strong)NSMutableArray    *dataArray;

@property (nonatomic,strong)UITableView       *tableView;

@end

@implementation ViewController

@end

5.2 一般变量命名

示例:

NSMutableArray  *ticketsArray = [NSMutableArrayarrayWithCapacity:0];

NSInteger numCompletedConnections =3;

5.3 常量命名

常量(预定义,枚举,局部常量等)使用小写k开头的驼峰法,比如kInvalidHandle ,

kWritePerm

示例:

#define kRunAnnotationStartPointTitle     @“起点"

typedef NS_ENUM (NSInteger,RunGoalTypeE){

kRunGoalTypeNone       = 0,    //无目标

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

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

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

};

NSString *const kGroupInfoName =@"name";

6. 图片资源文件命名 

先看下新浪微博app图片资源命名方式,下面是部分截图:

(转)ios 代码规范(转)ios 代码规范

这个图片资源命名方式,以功能为组织形式,是一个很好的习惯,有利于查看资源文件。

原则:

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

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

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

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

备注:建议背景图采用以bg作前缀,按钮背景采用btn作前缀(不作强制要求,项目实际

负责人根据团队特点确定即可)

公共模块命名示例:

导航条背影图片:bg_nav_bar@2x.png

导航返回按钮:bg_nav_back_normal@2x.png,bg_nav_back_selected@2x.png

标签item背景:bg_tabbar_record_normal@2x.png,bg_tabbar_record_selected@2x.png

私有模块命名示例:

以Joggers APP的用户中心图片资源为例说明,

uc——user center

用户中心头像默认图:bg_uc_avatar@2x.png

用户中心顶部默认背景图:bg_uc_top_defaut@2x.png

用户中心底部背景图:bg_uc_bottom@2x.png

这部分工作较为繁杂,并且在程序员心中会认为是技术含量较低的一个工作,但图片命名

的严谨性同样会反映出我们对细节的追求,细节决定成败。

文件组织结构

1. 类文件组织

iOS工程文件结构分物理结构和逻辑结构,建议逻辑结构和物理结构保持一致,以便方便有效地管理类文件。类文件组织要遵循以下两大原则:

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

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

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

2. 图片资源文件组织

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

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

下图是Joggers的文件组织结构:

(转)ios 代码规范

上图严格按照上述讨论组织文件结构,保持了物理/逻辑结构的统一,方便团队间查阅代

码,以及共享资源。

类代码组织原则

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

示例:

(转)ios 代码规范

(转)ios 代码规范

(转)ios 代码规范

(转)ios 代码规范

(转)ios 代码规范

第一部分主要对易把握的,易推广的,并且对团队开发中有实实在在帮助内容作简要论述,主要集中在命名,文件组织原则方面,并给了相应的示例。规范由各项目负责人具体执行。好像忘记一件什么事,没错,注释,上述没有对注释做专门的阐述,良好的代码习惯就是一个好的注释,因此这里不专门为注释作讨论,注释要求由各项目负责人来约定。

@傅总 团队要求

iOS代码规范

1 删除多余的空行
     * 所有方法与方法之间空1行
     * 所有代码块之间空1行
2 删除多余的注释
     * 删除注释掉的代码
     * 删除没有意义的注释
3 删除多余的方法
     * 如果方法没有使用到,请删除它
     * 如果方法没有执行任何业务逻辑,请删除它或者给出一定注释
4 删除未被使用的资源文件
5 添加必要的注释
     * 所有 .h 文件中的property 需要给出注释
     * 所有自定义的方法需要给出注释
     * 比较大的代码块需要给出注释
     * 所有代码中出现的阿拉伯数字需要给出注释
     * 程序中出现加密/解密 逻辑的操作地方,需要给出注释说明过程(无论是系统还是自定义)
6 整体代码风格需要统一
     * 代码后面的”{“ 不需要单独占用一行
     * 逻辑运算符 与 代码之前空一格
     * “#pragma mark -” 与下面的代码之前不要空行
     * 遵循一般性的代码规范

iOS通用规则

1 下面所有规则对第三方类库无约束
     * 所有类、方法、属性等命名,做到见名知意,采用驼峰式命名规则
     * 根据资源类型或者所属业务逻辑对项目资源进行分组,使得整个项目结构清晰明了
     * 整个项目保持一种代码书写风格(这个风格由无锡团队根据自己编码习惯来定),让你的代码变的优雅!
2. 命名规范
     * 所有类名称以项目工程开头命名,eg:“XP”、“ZJG”、“SZ”
     * 针对不同视图控制器,在末尾添加后缀,eg:
     * 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 对方法进行分组 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
     * #pragma mark - UITableViewDelegate Methods
     * #pragma mark - UITableViewDataSource Methods
     * #pragma mark - UIScrollViewDelegate Methods
     * #pragma mark - UITextFieldDelegate Methods
     * #pragma mark - UITextViewDelegate Methods

上一篇:标准IO缓冲详解全缓冲、行缓冲、不缓冲


下一篇:clipboard.js IE下 不允许复制时, 问题修改