iOS开发规范文档_第1页
iOS开发规范文档_第2页
iOS开发规范文档_第3页
iOS开发规范文档_第4页
iOS开发规范文档_第5页
已阅读5页,还剩10页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、iOS 开发规范命名本文推荐驼峰法,也是Objective-C 社区的标准。驼峰法分小驼峰法和大驼峰法。小驼峰法:除第一个单词之外,其他单词首字母大写。大驼峰法相比小驼峰法,大驼峰法把第一个单词的首字母也大写了。2. 类命名类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。类名中应该包含一个或多个名词来说明这个类(或者类的对象)是做什么的。在应用级别的代码里,尽量不要使用带前缀的类名。每个类都有相同的前缀不能提高可读性。不过如果是编写多个应用间的共享代码,前缀就是可接受并推荐的做法了(型如JKPhotoBrowser ) 。示例 1 :interface ImageBrowseView

2、:UIViewend示例 2:(带前缀JK)interface JKPhotoBrowser :UIViewend3. 类别命名类名+标识+扩展(UIImageView +HP+Web )例:如果我们想要创建一个基于UIImageView 的类别用于网络请求图片,我们应该把类别放到名字是UIImageView+HPWeb.h 的文件里。UIImageView 为要扩展的类名,HP 为专属标识, Web 为扩展的功能。类别的方法应该都使用一个前缀(型如hp_myCategoryMethodOnAString ), 以防止Objective-C 代码在单名空间里冲突。如果代码本来就不考虑共享或在不

3、同的地址空间(address-space) ,方法命名规则就没必要恪守了。类别 HPWeb 头文件,UIImageView+HPWeb.h 如下:interface UIImageView (HPWeb)- (void)hp_setImageWithURLString:(NSString *)urlStr;end4. 方法命名方法使用小驼峰法命名, 一个规范的方法读起来应该像一句完整的话,读过之后便知函数的作用。执行性的方法应该以动词开头,小写字母开头,返回性的方法应该以返回的内容开头,但之前不要加get。示例:- (void)replaceObjectAtIndex:(NSUInteger)

4、index withObject:(id)anObject;(instancetype)arrayWithArray:(NSArray *)array;如果有参数,函数名应该作为第一个参数的提示信息,若有多个参数,在参数前也应该有提示信息(一般不必加and)一些经典的操作应该使用约定的动词,如initWith,insert,remove,replace,add 等等。5. 变量命名变量名使用小驼峰法, 使变量名尽量可以推测其用途属性具有描述性。别一心想着少打几个字母,让你的代码可以迅速被理解更加重要。5.1 类成员变量:成员变量用小驼峰法命名并前缀下划线,Objective-C 2.0 , p

5、roperty 和 synthesize 提供了遵守命名规范的解决方法示例:interface ViewController ()*dataArray;property (nonatomic,strong)NSMutableArrayproperty (nonatomic,strong)UITableView*tableView;endimplementation ViewControllerend5.2 一般变量命名示例:NSMutableArray *ticketsArray = NSMutableArrayarrayWithCapacity:0;NSInteger numComplete

6、dConnections =3;5.3 常量命名常量(预定义,枚举,局部常量等)使用小写k 开头的驼峰法,比如kInvalidHandle ,kWritePerm示例:#define kRunAnnotationStartPointTitle“ 起点typedef NS_ENUM (NSInteger,RunGoalTypeE)= 0,/无目标= 1,/以时间为目标= 2,/以距离为目标= 3,/以消耗卡路里为目标kRunGoalTypeNonekRunGoalTypeTimekRunGoalTypeDistancekRunGoalTypeCalori;NSString *const kGro

7、upInfoName =name;6. 图片资源文件命名先看下新浪微博app 图片资源命名方式,下面是部分截图:common_icon_membershipjevel1 2x.png common_icon_membership_level13x.png common_icon_membershipjevel22x.png common_icon_membershipjevel23x.png common_icon_membership_level32x.png common_icon_membership_level33x.png common_icon_membership_level42

8、x.png common Jcon_membershipJevel43x.png common_icon_membershipjevel52x.png common_icon_membershipjevel53x.png common_icon_membership_level62x.png common Jcon_membershipJevel63x.pngII tabbar_compose_shooting.png I tabbar_compose_shooting2x.png 鱼 tabbar_compose_shooting3x.png O| tabbar_compose_transf

9、er3x.png 0| tabbar_compose_video2x.png | tabbar_compose_voice.png tabbar_compose_voice2x.png 曼 tabbar_compose_voice3x.png tabbar_compose_weibo.png tabbar_compose_weibo2x.png QI tabbar_compose_weibo3x.png这个图片资源命名方式,以功能为组织形式,是一个很好的习惯,有利于查看资源文件。原则:1 )采用单词全拼,或者大家公认无岐义的缩写(比如: nav, bg, btn 等 )2)采用“模块 +功能

10、”命名法,模块分为公共模块、私有模块。公共模块主要包括统一的背景,导航条,标签,公共的按钮背景,公共的默认图等等;私有模块主要根据app 的业务功能模块划分,比如用户中心,消息中心等备注:建议背景图采用以bg 作前缀,按钮背景采用btn 作前缀(不作强制要求,项目实际负责人根据团队特点确定即可)公共模块命名示例:导航条背影图片:bg_nav_bar2x.png导航返回按钮:bg_nav_back_normal2x.png , bg_nav_back_selected2x.png标签 item 背景: bg_tabbar_record_normal2x.png , bg_tabbar_recor

11、d_selected2x.png 私有模块命名示例:以 Joggers APP 的用户中心图片资源为例说明, uc user center用户中心头像默认图:bg_uc_avatar2x.png用户中心顶部默认背景图:bg_uc_top_defaut2x.png用户中心底部背景图:bg_uc_bottom2x.png这部分工作较为繁杂,并且在程序员心中会认为是技术含量较低的一个工作,但图片命名的严谨性同样会反映出我们对细节的追求,细节决定成败。文件组织结构1. 类文件组织iOS 工程文件结构分物理结构和逻辑结构,建议逻辑结构和物理结构保持一致,以便方便有效地管理类文件。类文件组织要遵循以下两大

12、原则:基于 MVC 设计模式原则,至少要保证controller 与数据处理,网络请求相对独立基于功能模块原则,功能模块分包括数据/网络处理,UI 前端界面两部分,数据/网络处理应该在数据/网络处理的框架下,而UI 前端界面比如用户中心,消息中心,它们的专有的controller , view 等应该在属于文件夹。还会遇到一些公共的view,可以开辟出公共的文件夹来管理在实际中使用中,项目实际负责人可以结合项目特点灵活使用,但基本的原则一定要保持, 保持良好的类文件组织结构,对团队有益无害。2. 图片资源文件组织图片资源文件,强烈建议采用Images.xcassets 管理,尽量少用自己创建的

13、文件夹管理。使用 Images.xcassets 的优势很多,具体可以查阅读相关文献资料,这里只从工程管理上说一点,在Images.xcassets 中添加图片资源,不会对project 文件造成改变,而直接在文件夹里添加图片文件,每次都会对project 文件造成改变,因此使用Images.xcassets 管理图片资源可以减少project 冲突的次数。下图是 Joggers 的文件组织结构:上图严格按照上述讨论组织文件结构,保持了物理/逻辑结构的统一,方便团队间查阅代码,以及共享资源。类代码组织原则一个原则:析构函数- (void)dealloc 最好放到类最上面,第一眼就可以看到这个方

14、法,可以方便看到是否remove 了一些操作,对内存的合理释放等,controller , view 的生命周期函数放到最上面,自己实现的方法在下面,相同/相近功能的方法采用#pragma mark - 来标记,以便查看。示例:M 9rt Ferninfo.Illi 咏rt CytwCcU.tru u H 2neHControUe* (K .一:1 YaMeiekOekegKQwtrty fiMOWa , F? 0Wrr” ,(HMitoMc. VHeblMiMEQUArr”;tebierifw;1viwCootrolUrH B9 nim-(v( :C )aMUM(.aasy an 3.muv

15、i*w.de b - .i:.”blay如 ej, ubl1it tpV/blog. Isdn. net /pjkl 129-vd 1 “igga/ 8 additlefial wtsjp ifttrviw, tyvtolly fro , 4KBDeso” ylw.tMr (tflCkor wUtteColerlilie I-Q- E-(oi)testData (卜 Muhb;*tMp (wy ):pmfod -579,”pimfol.cMe . MNrM2Mg.jpT: ItMp i :tpinfolj;9KshortM3e7RresultkArrfort (tew : : 44rrayu,

16、gC*MQt01AtiKMporiMfllWiult彳:objl, etJ2Pers9nlnfc epl (Rrsnlnf )gjl;Ptrswlnf 22 (Prnln(o tofej2; return (pl.hortNM CMMre:ol.lferVaM tloasMM*rlcSMrc 1;)J:域#国分机 VW郃骁H匿加k 1129-leArr .y JgetChknescStringArr;(h: A* : r )arrToSortnbloA, tteopArra/ (N tattrArriy arrantthCweittOl:NYtr:” snMe -。(, LOj ltrrTor

17、l covnt 1;cl$einaae plefo.shortHBw:MMuUbleA YNA iMSMutUleAf/fty “Mftffew!,QW6);ItespArrey (5d0b)4ct :dat);tOPpArr”;fpe* Mfk - UJTebleVinOataSourcc ( 51JnibertlfSect ionsInTableVlew: (LTTleVir- JtibleViewI,.d2r” t2leYhew; W【心 c ic )“6uY】ev rxjBber9fRowsln5ecanM;l, i teoc lsection;o r (ir f.dataArray

18、ebje rtAflrdt-zjjeetlal tj:-(ir.Lirv !-wt - : i 八检,Stgiqvia什;)Index% thlUtic MSStflfJleletlentifiJp 1rPC t / P jk 11211 cell - (CustorfeU )(tblVlv RWtoM*blcCUVUMcr :CtlUdeMifterh . f (cell = r1 ,J cell | (CustoACell. alloc) in styleturTabteVieUStyleOeuIt ret0eMmtifAori CelUMMiflerl;crll. w”f“y &” Ic

19、b)m lc-i IlMeMtath ( 110 JJ;cell.plnfo (data oojeef Atir.(jp.:indexPath.rcMrj ; CtVl;第一部分主要对易把握的,易推广的,并且对团队开发中有实实在在帮助内容作简要论述,没错, 注释, 上述没有对注释做专门的阐述,良好的代码习惯就是一 傅总团队要求iOS 代码规范1 删除多余的空行* 所有方法与方法之间空1 行* 所有代码块之间空1 行2 删除多余的注释* 删除注释掉的代码* 删除没有意义的注释3 删除多余的方法* 如果方法没有使用到,请删除它* 如果方法没有执行任何业务逻辑,请删除它或者给出一定注释4 删除未被使

20、用的资源文件5 添加必要的注释* 所有 .h 文件中的property 需要给出注释* 所有自定义的方法需要给出注释* 比较大的代码块需要给出注释* 所有代码中出现的阿拉伯数字需要给出注释* 程序中出现加密解密逻辑的操作地方,需要给出注释说明过程(无论是系统还是自定义)6 整体代码风格需要统一* 代码后面的” “ 不需要单独占用一行* 逻辑运算符与代码之前空一格* “ #pragma mark -” 与下面的代码之前不要空行* 遵循一般性的代码规范iOS 通用规则1 下面所有规则对第三方类库无约束* 所有类、方法、属性等命名,做到见名知意,采用驼峰式命名规则* 根据资源类型或者所属业务逻辑对项

21、目资源进行分组,使得整个项目结构清晰明了* 整个项目保持一种代码书写风格(这个风格由无锡团队根据自己编码习惯来定),让你的代码变的优雅!2. 命名规范* 所有类名称以项目工程开头命名,eg: “ XP、” “ ZJG”、 “ SZ”* 针对不同视图控制器,在末尾添加后缀,eg:* UIViewController 后缀添加“ ViewController ”* UIView 后缀添加“ View”* UIButton 后缀添加“ Button* UILabel 后缀添加“ Label3. 单页代码最好控制在800 行以内,每个方法最好不要超过100 行,过多建议对代码进行重构4. 相同的逻辑方法定义避免在多个地方出现,尽量将公用的类、方法抽取出来5. 删除未被使用的代码,不要

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论