iOS 代码规范

一、命名规范

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

1、驼峰法

objective-c社区的标准，驼峰法分小驼峰法和大驼峰法。小驼峰法：除第一个单词之外，其他单词首字母大写，一般用于变量命名。大驼峰法相比小驼峰法，大驼峰法把第一个单词的首字母也大写了，一般用于对象命名。

2、基本原则

1） 清晰（可读性高）

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

2） 一致性

做某个事情代码通常都叫这个名字，比如tag、setstringvalue，那么你也这么叫。你在不确定怎么起名字的时候，可以参考一些常用的名字：method arguments

3）禁止使用中文或拼音（英文不好？ 有道一下啦）

3. 类命名

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

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

4. 类别命名（category）

类名+标识+扩展（uiimageview +hp+web）

类别的方法应该都使用一个前缀(型如hp_mycategorymethodonastring ),以防止objective-c代码在单名空间里冲突。如果代码本来就不考虑共享或在不同的地址空间(address-space)，方法命名规则就没必要恪守了。

5. 方法命名

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

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

开头，但之前不要加get。

6. 变量命名

1）变量名使用小驼峰法, 使变量名尽量可以推测其用途属性具有描述性。必须起有意义的名字，使其他组员可以很容易读懂变量所代表的意义，变量命名可以采用同义的英文命名，可使用几个英文单词。别一心想着少打几个字母，让你的代码可以迅速被理解更加重要。

2）对于一些特殊类型的变量，命名时要带上类型，如nsarray 的变量命名为xxxarray 或xxxlist，其他的如xxxdictionary，xxxsize等。这样就可以从名称上知道是什么类型的变量。千万不能将nsarray的变量命名为xxxdictionary。

3）对于ui控件变量，命名时后缀要以特定的控件名。

如：@property (weak, nonatomic) iboutlet uilabel *versionlabel;

4）控制器的后缀必须加viewcontroller， 名字过长的情况下也必须加上controller作为后缀；

5） 普通view后缀必须加view，uitableviewcell和uicollectionviewcell后缀必须加cell；

6）成员变量命名，尽量采用@property方式来申明变量，如果不用@property方式申明变量，则必须采用前缀下划线来申明变量

7. 常量命名

1）对于常量的命名最好在前面加上字母k作为标记. 如:

static const nstimeinterval kanimationduration = 0.3;

2）定义作为nsdictionary或者notification等的key值字符串时加上const关键字, 以防止被修改，通知的name一定要以notification作为后缀。如:

nsstring *const uiapplicationdidenterbackgroundnotification

3） 避免在程序中直接出现常数，使用超过一次的应以宏定义的形式来替代。

8. 枚举命名

枚举类型命名要加相关类名前缀并且枚举值命名要加枚举类型前缀.

typedef ns_enum(nsinteger, uiviewanimationtransition) {

uiviewanimationtransitionnone,

uiviewanimationtransitionflipfromleft,

uiviewanimationtransitionflipfromright,

uiviewanimationtransitioncurlup,

uiviewanimationtransitioncurldown,

};

9. 图片资源文件命名

原则：

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

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

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

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

注：assets.xcassets中文件夹必须分模块，命名必须小写，图片必须命名好之后再放入assets.xcassets中。通常来说，assets中至少包含common，tabbar，navigation这三个模块。

公共模块命名示例：

背景图采用以bg作后缀缀，按钮背景采用btn作后缀;

导航条背影图片：[e-mail]

导航返回按钮：[e-mail]

标签item背景：[e-mail]，[e-mail]

通用cell占位图：[e-mail]

私有模块命名示例：

以用户中心图片资源为例说明：

用户中心头像默认图：[e-mail]

用户中心顶部默认背景图：[e-mail]

9. 目录命名

用英文命名时，首字母大写，可以用中文命名，但是禁止使用拼音命名。

二、编码排版格式

1、代码的缩进应使用空格（space），不能使用制表符（tab），并且缩进以2个 字符为单位。快捷方式：command + a —— > control + i

2、 中括弧的每一个括弧在源程序中要单独占一行。

3、 空格的使用

a) 关键字与其后的表达式之间要有空格

b) 单目操作符不应与它们的操作数分开（如’!’和’^’等）。

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

d) .h中协议<>前面有一个空格。

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

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

g) 方法的+，-后面与（）之间留1个空格。

h) 返回类型与*之间留1个空格，方法参数中返回类型与*之间留1个空格。

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

4、 每行只能有一个语句

5、关于空行

a) .h中的空行

• 1、文件说明与头文件包含(#import)之间空1行
• 2、头文件包含(#import)之间，如果需要分类区别，各类别之间空1行。
• 3、头文件包含(#import)与@class之间空2行。
• 4、@interface与@class之间空1行。
• 5、头文件{}里面，空1行开始声明对象成员，如果需要分类区别，各类别之间空1行。
• 6、头文件{}外，空1行书写属性，如果需要分类区别，各类别之间空1行。
• 7、属性下面空1行开始写方法，如果需要分类区别，各类别之间空1行。
• 8、方法完成后，空1行@end。
• 9、如果需要声明protocol，空2行接着写。通常protocol写在@end后面，但是声明在@interface之前。

  b) .m中的空行

• 1、文件说明与头文件包含(#import)之间空1行
• 2、头文件包含(#import)之间，如果需要分类区别，各类别之间空1行。
• 3、@implementation和@synthesize之间空1行, 如果需要分类区别，各类别之间空1行。
• 4、方法与方法之间空1行。

  c) 方法里面的空行

• 1、变量声明后需要空1行，如果需要分类区别，各类别之间空1行。
• 2、条件、循环，选择语句，整个语句结束，需要空1行。
• 3、各功能快之间空1行。
• 4、最后一个括弧之前不空行。
• 5、注释与代码之间不空行。
• 6、#pragma mark 与方法之间空1行。

d) 每行代码最多不得操作100个字。设置如下：xcode => preferences => textediting => page guide at column /输入 100即可。

6、注释

1、变量名、方法名等不足以说明实际意义的时候，必须要写注释；

2、类名不足以提现类的作用的时候，必须在类声明的上面添加注释，说明类的基本作用。

3、可能涉及到注释的地方主要包括：

类注释、方法注释、成员变量注释、枚举注释、宏定义注释、宏定义方法注释、逻辑注释、protocol注释

4、推荐使用vvdocumenter

7、文件夹：所有新建的目录，在工程下必须存在实体目录；

8、单页面代码不得超过800行，单个方法不得超过50行。

3 、规定

1、 dealloc方法 规定：一个类的dealloc方法如果有必要存在，必须是.m中的最后一个方法，方便查找；

2、非特殊需要，不允许将ui控件的property直接创建到.h文件中；

3、当需要一定条件才执行某项操作时，最左边的应该是最重要的代码，不要将最重要的代码内嵌到if中。

如良好的风格是：

- (void) somemethod {

if(![someother boolvalue]) {

return;

}

//最重要的代码写在这里；

}

反面教材：

- (void) somemethod {

if([someother boolvalue]) {

//重要代码；

}

}

4 、建议

1、尽量不使用for循环，可用forin或者enumerateobjectsusingblock进行遍历；

2、尽可能保证 .h文件的简洁性，可以不公开的api就不要公开了，写在实现文件中即可；

3、建议使用“#pragma mark”，方便代码。有些由于数据等方面问题需要以后做处理的使用#pragma warnning”进行提醒;

4、if-else超过四层的时候，就要考虑重构，多层的if-else结构很难维护；

5、uiview的子类初始化的时候，不要进行任何的布局操作。布局操作应该在layoutsubviews里面做；需要重新布局的时候调用setneedslayout，而不要直接调用layoutsubviews。（一般代码创建的时候这样做）；

6、推荐方法的第一个花括号直接跟在方法体后，而不是另起一行，这样可以减少代码行；

7、方法体中的第一行留空，最后一行不留空，这样一个方法就会比较清晰，但是如果该花括号里面又是一个if，for之类的带花括号的语句块，那么上述的第一行可以不留空。

同样，如果花括号内第一行是注释的话，第一行也可以不留空。注释也起到了分隔代码的作用，看起来比较清晰。

再者，如果花括号内只有一行代码，第一行可以不留空。du -k repos