ios开发要求规范文档.docx
- 文档编号:7879890
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:18
- 大小:2MB
ios开发要求规范文档.docx
《ios开发要求规范文档.docx》由会员分享,可在线阅读,更多相关《ios开发要求规范文档.docx(18页珍藏版)》请在冰豆网上搜索。
ios开发要求规范文档
命名
命名规如此对于维护代码来说是非常重要的,。
Objective-C方法名往往很长,不过这也有好处,让很多注释变得毫无意义。
本文推荐驼峰法,也是Objective-C社区的标准。
驼峰法分小驼峰法和大驼峰法。
小驼峰法:
除第一个单词之外,其他单词首字母大写。
大驼峰法相比小驼峰法,大驼峰法把第一个单词的首字母也大写了。
1.1清晰
又清晰又简洁是最好的了,但简洁不如清晰重要。
总的讲不要使用单词的简写,除了非常常用的简写以外,尽量使用单词全称。
API的名称不要有歧义,一看你的API就知道是以什么方式做了什么事情,不要让人有疑问
1.2一致性
做某个事情代码通常都叫这个名字,比如tag、setStringValue,那么你也这么叫。
你在不确定怎么起名字的时候,可以参考一些常用的名字:
MethodArguments
2.类命名
类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。
类名中应该包含一个或多个名词来说明这个类〔或者类的对象〕是做什么的。
在应用级别的代码里,尽量不要使用带前缀的类名。
每个类都有一样的前缀不能提高可读性。
不过如果是编写多个应用间的共享代码,前缀就是可承受并推荐的做法了(型如MBAPhotoBrowser)。
示例1:
interface ImageBrowseView:
UIView
end
示例2:
〔带前缀MBA〕
interface MBAPhotoBrowser:
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.方法命名
方法使用小驼峰法命名,一个规X的方法读起来应该像一句完整的话,读过之后便知函数
的作用。
执行性的方法应该以动词开头,小写字母开头,返回性的方法应该以返回的内容
开头,但之前不要加get。
示例:
-(void)replaceObjectAtIndex:
(NSUInteger)indexwithObject:
(id)anObject;
(instancetype)arrayWithArray:
(NSArray *)array;
如果有参数,函数名应该作为第一个参数的提示信息,假如有多个参数,在参数前也应该有
提示信息〔一般不必加and〕
一些经典的操作应该使用约定的动词,如initWith,insert,remove,replace,add等等。
5.变量命名
变量名使用小驼峰法,使变量名尽量可以推测其用途属性具有描述性。
别一心想着少打几
个字母,让你的代码可以迅速被理解更加重要。
5.1类成员变量:
成员变量用小驼峰法命名并前缀下划线,Objective-C2.0,property和synthesize提供
了遵守命名规X的解决方法
示例:
interface ViewController ()
property (nonatomic,strong)NSMutableArray *mDataArray;
property (nonatomic,strong)UITableView *mtableView;
end
implementation ViewController
end
5.2一般变量命名
示例:
NSMutableArray *ticketsArray=[NSMutableArrayarrayWithCapacity:
0];
NSInteger numpletedConnections=3;
5.3常量命名
常量(预定义,枚举,局部常量等)使用小写k开头的驼峰法,比如kInvalidHandle,
kWritePerm
示例:
#definekRunAnnotationStartPointTitle “起点"
typedef NS_ENUM (NSInteger,RunGoalTypeE){
kRunGoalTypeNone = 0, //无目标
kRunGoalTypeTime = 1, //以时间为目标
kRunGoalTypeDistance = 2, //以距离为目标
kRunGoalTypeCalori = 3, //以消耗卡路里为目标
};
NSString *const kGroupInfoName="name";
6.图片资源文件命名
先看下新浪微博app图片资源命名方式,下面是局部截图:
这个图片资源命名方式,以功能为组织形式,是一个很好的习惯,有利于查看资源文件。
原如此:
1〕采用单词全拼,或者大家公认无岐义的缩写(比如:
nav,bg,btn等)
2〕采用“模块+功能〞命名法,模块分为公共模块、私有模块。
公共模块主要包括统一的背
景,导航条,标签,公共的按钮背景,公共的默认图等等;私有模块主要根据app的业务
功能模块划分,比如用户中心,消息中心等
备注:
建议背景图采用以bg作前缀,按钮背景采用btn作前缀〔不作强制要求,项目实际
负责人根据团队特点确定即可〕
公共模块命名示例:
私有模块命名示例:
以JoggersAPP的用户中心图片资源为例说明,
uc——usercenter
这局部工作较为繁杂,并且在程序员心中会认为是技术含量较低的一个工作,但图片命名
的严谨性同样会反映出我们对细节的追求,细节决定成败。
文件组织结构
1.类文件组织
iOS工程文件结构分物理结构和逻辑结构,建议逻辑结构和物理结构保持一致,以便方便有效地管理类文件。
类文件组织要遵循以下两大原如此:
基于MVC设计模式原如此,至少要保证controller与数据处理,网络请求相对独立
基于功能模块原如此,功能模块分包括数据/网络处理,UI前端界面两局部,数据/网络处理应该在数据/网络处理的框架下,而UI前端界面比如用户中心,消息中心,它们的专有的controller,view等应该在属于文件夹。
还会遇到一些公共的view,可以开辟出公共的文件夹来管理
在实际中使用中,项目实际负责人可以结合项目特点灵活使用,但根本的原如此一定要保持,保持良好的类文件组织结构,对团队有益无害。
2.图片资源文件组织
图片资源文件,强烈建议采用Images.xcassets管理,尽量少用自己创建的文件夹管理。
使用Images.xcassets的优势很多,具体可以查阅读相关文献资料,这里只从工程管理上说一点,在Images.xcassets中添加图片资源,不会对project文件造成改变,而直接在文件夹里添加图片文件,每次都会对project文件造成改变,因此使用Images.xcassets管理图片资源可以减少project冲突的次数。
如下图是Joggers的文件组织结构:
上图严格按照上述讨论组织文件结构,保持了物理/逻辑结构的统一,方便团队间查阅代
码,以与共享资源。
类代码组织原如此
一个原如此:
析构函数-(void)dealloc最好放到类最上面,第一眼就可以看到这个方法,可以方便看到是否remove了一些操作,对内存的合理释放等,controller,view的生命周期函数放到最上面,自己实现的方法在下面,一样/相近功能的方法采用#pragmamark-来标记,以便查看。
示例:
第一局部主要对易把握的,易推广的,并且对团队开发中有实实在在帮助内容作简要论述,主要集中在命名,文件组织原如此方面,并给了相应的示例。
规X由各项目负责人具体执行。
好似忘记一件什么事,没错,注释,上述没有对注释做专门的阐述,良好的代码习惯就是一个好的注释,因此这里不专门为注释作讨论,注释要求由各项目负责人来约定。
团队要求
iOS代码规X1删除多余的空行 *所有方法与方法之间空1行 *所有代码块之间空1行2删除多余的注释 *删除注释掉的代码 *删除没有意义的注释3删除多余的方法 *如果方法没有使用到,请删除它 *如果方法没有执行任何业务逻辑,请删除它或者给出一定注释4删除未被使用的资源文件5添加必要的注释 *所有.h文件中的property需要给出注释 *所有自定义的方法需要给出注释 *比拟大的代码块需要给出注释 *所有代码中出现的阿拉伯数字需要给出注释 *程序中出现加密/解密逻辑的操作地方,需要给出注释说明过程〔无论是系统还是自定义〕6整体代码风格需要统一 *代码后面的〞{“不需要单独占用一行 *逻辑运算符与代码之前空一格 *“#pragmamark-〞与下面的代码之前不要空行 *遵循一般性的代码规XiOS通用规如此1下面所有规如此对第三方类库无约束 *所有类、方法、属性等命名,做到见名知意,采用驼峰式命名规如此 *根据资源类型或者所属业务逻辑对项目资源进展分组,使得整个项目结构清晰明了 *整个项目保持一种代码书写风格〔这个风格由某某团队根据自己编码习惯来定〕,让你的代码变的优雅!
2.命名规X *所有类名称以项目工程开头命名,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.请多使用#pragmamark-MarkName对方法进展分组eg:
*#pragmamark-ViewlifeCycle *#pragmamark-ViewlifeTerm *#pragmamark-Initmethods *#pragmamark-Actionmethods *#pragmamark-monmethods *#pragmamark-UIActionSheetDelegate *#pragmamark-UIImagePickerControllerDelegate *#pragmamark-UITableViewDelegateMethods *#pragmamark-UITableViewDataSourceMethods *#pragmamark-UIScrollViewDelegateMethods *#pragmamark-UITextFieldDelegateMethods *#pragmamark-UITextViewDelegateMethods
1.代码行度最大为100列
2.声明类或方法时,注意空格的使用,参数过多时可换行保持对齐,
调用方法时也是如此,参数都写在一行或换行冒号对齐,
3.命名规如此
类名首字母大写,方法首字母小写,方法中的参数首字母小写,同时尽量让方法的命名读起来像一句话,能够传达出方法的意思,同时取值方法前不要加前缀“get〞
变量名小写字母开头
常量以小写字母k开头,后续首字母大写
4.关于注释
注释很重要,但除了开头的声明,尽可能把代码写的如同文档一样,让别人直接看代码就知道意思,写代码时别担心名字太长,相信Xcode的提示功能。
5.实例变量应该在实现文件.m中声明或以property形式在.h文件中声明,一定要直接在.h文件声明,加上priavte,另外,使用private、public,前面需要一个缩进空格。
6.尽可能保证.h文件的简洁性,可以不公开的API就不要公开了,写在实现文件中即可。
支持Objective-C/C/C++混编,所以引用头文件时:
#importOective-C/Objective-C++头文件〔Objective-C++是Objective-C与C++混编的文件〕,#includeC/C++头文件。
8.写delegate的时候类型应该为weak弱引用,以防止循环引用,当delegate对象不存在后,我们写的delegate也就没有存在意义了自然是需要销毁的,weak与strong可以参考上一篇文章介绍。
9.实例变量声明时变量名前面加下划线“_〞,局部变量不用加。
10.使用Block时,内容四个空格缩进,“^〞后带有参数时,参数与“{〞之间有一个空格缩进
11.建议使用“#pragmamark〞,方便阅读代码
属性命名
描述性的单词+变量类型是最好的,一目了然例如:
UILabel*nameLabel;
类命名
前缀+描述+类型
注:
前缀可以是你的某某/昵称等主要用于团队开发的时候防止文件名重复
以下是我个人命名方式例:
XJX ---某某/昵称
Message ---描述性本类的功能
Cell/Model ---类型/模型
方法命名
方法使用小驼峰法命名
一个规X的方法读起来应该像一句完整的话,读过之后便知函数的作用。
执行性的方法应该以动词开头,小写字母开头。
返回性的方法应该以返回的内容开头,但之前不要加get。
示例:
-(void)replaceObjectAtIndex:
(NSUInteger)indexwithObject:
(id)anObject;
-(instancetype)arrayWithArray:
(NSArray*)array;
常量命名
通常与项目设置的类文件前缀一样,跟随其后的命名应采用驼峰命名法如此,命名应准确表述常量表示的意义。
示例:
#define kRunAnnotationStartPointTitle “起点"
typedefNS_ENUM(NSInteger,UITableViewStyle){
UITableViewStylePlain, //regulartableview
UITableViewStyleGrouped //preferencesstyletableview
};
NSString*constUIApplicationLaunchOptionsRemoteNotificationKey;
NSString*constUIApplicationLaunchOptionsLocalNotificationKey;
图片命名
原如此:
1〕采用单词全拼,或者大家公认无岐义的缩写(比如:
nav,bg,btn等)
2〕采用“模块+功能〞命名法,模块分为公共模块、私有模块。
公共模块主要包括统一的背
景,导航条,标签,公共的按钮背景,公共的默认图等等;私有模块主要根据app的业务
功能模块划分,比如用户中心,消息中心等
备注:
建议背景图采用以bg作前缀,按钮背景采用btn作前缀〔不作强制要求,项目实际
负责人根据团队特点确定即可〕
公共模块命名示例:
私有模块命名示例:
以土冒APP的首页图片资源为例说明,
函数命名
如果有参数,函数名应该作为第一个参数的提示信息,假如有多个参数,在参数前也应该有提示信息〔一般不必加and〕
一些经典的操作应该使用约定的动词,如initWith,insert,remove,replace,add等等。
代码注释
提与命名,不得不马上提醒代码的注释问题!
很多同事的注释过于粗糙,有些甚至都没有注释习惯,导致代码可读性差,版本迭代或是需求变更的时候不能与时定位到具体代码
以下已model类为例:
/**名字*/
property(nonatomic,strong)NSString*name;
/**年龄*/
property(nonatomic,strong)NSString*age;
/**性别*/
property(nonatomic)BOOLsex;
注释统一采用文档注释方式:
/** */
这样注释的好处是:
当你调用这个属性时会具有相关备注提示例:
题外话-Xcode插件-VVDocumenter
这是一个文档注释插件,可以帮助开发者快速的注释,提高工作效率,这也是本人比拟常用的一款插件,具体效果请前往github查看
附上github:
s:
//github./onevcat/VVDocumenter-Xcode
代码组织
在函数分组和protocol/delegate实现中使用#pragmamark-来分类方法:
#pragmamark-Lifecycle
-(id)init{}
-(void)dealloc{}
-(void)viewDidLoad{}
-(void)viewWillAppear:
(BOOL)animated{}
-(void)didReceiveMemoryWarning{}
#pragmamark-CustomAccessors
-(void)setUpTableView{}
#pragmamark-IBActions
-(IBAction)submitData:
(id)sender{}
#pragmamark-Public
-(void)publicMethod{}
#pragmamark-Private
-(void)privateMethod{}
#pragmamark-Protocolconformance
#pragmamark-UITextFieldDelegate
#pragmamark-UITableViewDataSource
#pragmamark-UITableViewDelegate
#pragmamark-NSCopying
-(id)copyWithZone:
(NSZone*)zone{}
#pragmamark-NSObject
-(NSString*)description{}
有人可能不明白这种注释的好处,上两X比照图大家可以直观的感觉一下
未注释
注释
作用
告诉Xcode编译器,要在编译器窗格顶部的方法和函数弹出菜单中将代码分隔开.
一些类(尤其是一些控制器类)可能代码量非常大,方法和函数弹出菜单可以便于代码导航.此时参加#pragma指令对代码进展逻辑组织就显得非常有效果
黄金路径
当使用条件语句编码时,左手边的代码应该是"golden"或"happy"路径。
也就是不要嵌套if语句,多个返回语句也是OK。
应该:
-(void)someMethod{
if(!
[someOtherboolValue]){
return;
}
//Dosomethingimportant
}
不应该
-(void)someMethod{
if([someOtherboolValue]) {
//Dosomethingimportant
}
}
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ios 开发 要求 规范 文档