欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  移动技术

iOS 代码规范

程序员文章站 2022-06-02 22:21:32
一、命名规范 命名规则对于维护代码来说是非常重要的,。objective-c方法名往往很长,不过这也有好处,让很多注释变得毫无意义。 1、驼峰法 objective-c社区的标准,驼峰法分小驼峰法和...

一、命名规范

命名规则对于维护代码来说是非常重要的,。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作后缀;

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

导航返回按钮:nav_back@2tx.png

标签item背景:tabbar_record_normal@2x.png,tabbar_record_selected@2x.png

通用cell占位图:common_cell_placeholder@2x.png

私有模块命名示例

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

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

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

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