ios开发规范文档

1、命名命名规则对于维护代码来说是非常重要的,。Objective-C方法名往往很长，不过这也有好处，让很多注释变得毫无意义。本文推荐驼峰法，也是Objective-C社区的标准。 驼峰法分小驼峰法和大驼峰法。小驼峰法：除第一个单词之外，其他单词首字母大写。大驼峰法相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。1.基本原则1.1 清晰又清晰又简洁是最好的了，但简洁不如清晰重要。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。API的名称不要有歧义，一看你的API就知道是以什么方式做了什么事情，不要让人有疑问1.2 一致性做某个事情代码通常都叫这个名字，比如tag

2、、setStringValue，那么你也这么叫。你在不确定怎么起名字的时候，可以参考一些常用的名字：Method Arguments2. 类命名类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。类名中应该包含一个或多个名词来说明这个类（或者类的对象）是做什么的。在应用级别的代码里，尽量不要使用带前缀的类名。每个类都有相同的前缀不能提高可读性。不过如果是编写多个应用间的共享代码，前缀就是可接受并推荐的做法了(型如 MBAPhotoBrowser )。示例1：interface ImageBrowseView :UIViewend示例2：（带前缀MBA）interface 

3、;MBAPhotoBrowser :UIViewend3. 类别命名类名+标识+扩展（UIImageView +HP+Web）例：如果我们想要创建一个基于UIImageView 的类别用于网络请求图片，我们应该把类别放到名字是UIImageView+HPWeb.h的文件里。UIImageView为要扩展的类名，HP为专属标识，Web为扩展的功能。类别的方法应该都使用一个前缀(型如hp_myCategoryMethodOnAString ),以防止Objective-C代码在单名空间里冲突。如果代码本来就不考虑共享或在不同的地址空间(address-space)，方法命名规则就没必要恪守了。类别

4、HPWeb头文件，UIImageView+HPWeb.h如下：interface UIImageView (HPWeb)- (void)hp_setImageWithURLString:(NSString *)urlStr;end4. 方法命名 方法使用小驼峰法命名, 一个规范的方法读起来应该像一句完整的话，读过之后便知函数的作用。执行性的方法应该以动词开头，小写字母开头，返回性的方法应该以返回的内容开头，但之前不要加get。示例：- (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObj

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

6、nthesize 提供了遵守命名规范的解决方法示例：interface ViewController ()property (nonatomic,strong)NSMutableArray    *mDataArray;property (nonatomic,strong)UITableView       *mtableView;endimplementation ViewControllerend5.2 一般变量命名       

7、 示例：NSMutableArray  *ticketsArray = NSMutableArrayarrayWithCapacity:0;    NSInteger numCompletedConnections =3;5.3 常量命名 常量(预定义，枚举，局部常量等)使用小写k开头的驼峰法，比如kInvalidHandle , kWritePerm 示例：#define kRunAnnotationStartPointTitle     “起点"typedef NS_EN

8、UM (NSInteger,RunGoalTypeE)    kRunGoalTypeNone       = 0,    /无目标    kRunGoalTypeTime       = 1,    /以时间为目标    kRunGoalTypeDistance   = 2,    /以距离为目标    kRunGoalTypeCalori &#

9、160;   = 3,    /以消耗卡路里为目标;NSString *const kGroupInfoName ="name"6. 图片资源文件命名 先看下新浪微博app图片资源命名方式，下面是部分截图：这个图片资源命名方式，以功能为组织形式，是一个很好的习惯，有利于查看资源文件。原则：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_record_selected2x.png私有模块命名示例：以Joggers APP的用户中心图片资源为例说明，ucuser center用户中心头像默认

11、图：bg_uc_avatar2x.png用户中心顶部默认背景图：bg_uc_top_defaut2x.png用户中心底部背景图：bg_uc_bottom2x.png这部分工作较为繁杂，并且在程序员心中会认为是技术含量较低的一个工作，但图片命名的严谨性同样会反映出我们对细节的追求，细节决定成败。文件组织结构1. 类文件组织iOS工程文件结构分物理结构和逻辑结构，建议逻辑结构和物理结构保持一致，以便方便有效地管理类文件。类文件组织要遵循以下两大原则：基于MVC设计模式原则，至少要保证controller与数据处理，网络请求相对独立基于功能模块原则，功能模块分包括数据/网络处理，UI前端界面两部分，

12、数据/网络处理应该在数据/网络处理的框架下，而UI前端界面比如用户中心，消息中心，它们的专有的controller，view等应该在属于文件夹。还会遇到一些公共的view，可以开辟出公共的文件夹来管理在实际中使用中，项目实际负责人可以结合项目特点灵活使用，但基本的原则一定要保持，保持良好的类文件组织结构，对团队有益无害。2. 图片资源文件组织图片资源文件，强烈建议采用Images.xcassets管理，尽量少用自己创建的文件夹管理。使用Images.xcassets的优势很多，具体可以查阅读相关文献资料，这里只从工程管理上说一点，在Images.xcassets中添加图片资源，不会对proje

13、ct文件造成改变，而直接在文件夹里添加图片文件，每次都会对project文件造成改变，因此使用Images.xcassets管理图片资源可以减少project冲突的次数。下图是Joggers的文件组织结构：上图严格按照上述讨论组织文件结构，保持了物理/逻辑结构的统一，方便团队间查阅代码，以及共享资源。类代码组织原则一个原则：析构函数- (void)dealloc最好放到类最上面，第一眼就可以看到这个方法，可以方便看到是否remove了一些操作，对内存的合理释放等，controller，view的生命周期函数放到最上面，自己实现的方法在下面，相同/相近功能的方法采用#pragma mark -来

14、标记，以便查看。示例：  第一部分主要对易把握的，易推广的，并且对团队开发中有实实在在帮助内容作简要论述，主要集中在命名，文件组织原则方面，并给了相应的示例。规范由各项目负责人具体执行。好像忘记一件什么事，没错，注释，上述没有对注释做专门的阐述，良好的代码习惯就是一个好的注释，因此这里不专门为注释作讨论，注释要求由各项目负责人来约定。团队要求iOS代码规范1 删除多余的空行     * 所有方法与方法之间空1行     * 所有代码块之间空1行2 删除多余的注释     * 删除注释掉

15、的代码     * 删除没有意义的注释3 删除多余的方法     * 如果方法没有使用到，请删除它     * 如果方法没有执行任何业务逻辑，请删除它或者给出一定注释4 删除未被使用的资源文件5 添加必要的注释     * 所有 .h 文件中的property 需要给出注释     * 所有自定义的方法需要给出注释     * 比较大的代码块需要给出注释     * 所有代码中出现的阿拉

16、伯数字需要给出注释     * 程序中出现加密解密 逻辑的操作地方，需要给出注释说明过程（无论是系统还是自定义）6 整体代码风格需要统一     * 代码后面的”“ 不需要单独占用一行     * 逻辑运算符 与 代码之前空一格     * “#pragma mark -” 与下面的代码之前不要空行     * 遵循一般性的代码规范iOS通用规则1 下面所有规则对第三方类库无约束     * 所有类、方法、属性等命名

17、，做到见名知意，采用驼峰式命名规则     * 根据资源类型或者所属业务逻辑对项目资源进行分组，使得整个项目结构清晰明了     * 整个项目保持一种代码书写风格（这个风格由无锡团队根据自己编码习惯来定），让你的代码变的优雅！2. 命名规范     * 所有类名称以项目工程开头命名，eg：“XP”、“ZJG”、“SZ”     * 针对不同视图控制器，在末尾添加后缀，eg：     * UIViewController  后缀添加“Vi

18、ewController”     * UIView 后缀添加“View”     * UIButton 后缀添加“Button"     * UILabel 后缀添加“Label"3. 单页代码最好控制在800行以内，每个方法最好不要超过100行，过多建议对代码进行重构4. 相同的逻辑方法定义避免在多个地方出现，尽量将公用的类、方法抽取出来5. 删除未被使用的代码，不要大片注释未被使用的代码，确定代码不会使用，请及时删除6. 对其他项目中copy过来的代码，根据具体需要更新代码风格，

19、及时删除未被使用的代码7. 项目中所有Group或者文件名称（图片名字等），不要使用汉字命名，尽量使用英文命名，国内特有名词可以使用拼音。8. 项目中所有Group都需要在项目目录中存在一个真实的目录，Group中的文件与真实目录中文件一一对应。9. 请在项目中写必要代码的注释10. 请多使用 #pragma mark - Mark Name 对方法进行分组 eg:     * #pragma mark - View lifeCycle     * #pragma mark - View lifeTerm    &

20、#160;* #pragma mark - Init methods     * #pragma mark - Action methods     * #pragma mark - Common methods     * #pragma mark - UIActionSheetDelegate     * #pragma mark - UIImagePickerControllerDelegate     * #pragma mark - U

21、ITableViewDelegate Methods     * #pragma mark - UITableViewDataSource Methods     * #pragma mark - UIScrollViewDelegate Methods     * #pragma mark - UITextFieldDelegate Methods     * #pragma mark - UITextViewDelegate Methods 1.代码行度最大为1

22、00列2.声明类或方法时，注意空格的使用，参数过多时可换行保持对齐，调用方法时也是如此，参数都写在一行或换行冒号对齐， 3.命名规则    类名首字母大写，方法首字母小写，方法中的参数首字母小写，同时尽量让方法的命名读起来像一句话，能够传达出方法的意思，同时取值方法前不要加前缀“get”变量名小写字母开头常量以小写字母k开头，后续首字母大写 4.关于注释 注释很重要，但除了开头的版权声明，尽可能把代码写的如同文档一样，让别人直接看代码就知道意思，写代码时别担心名字太长，相信Xcode的提示功能。 5.实例变量应该在实现文件.

23、m中声明或以property形式在.h文件中声明，一定要直接在.h文件声明，加上priavte，另外，使用private、public，前面需要一个缩进空格。 6.尽可能保证 .h文件的简洁性，可以不公开的API就不要公开了，写在实现文件中即可。 7.Xcode支持Objective-C/C/C+混编，所以引用头文件时：#import Ojbective-C/Objective-C+头文件（Objective-C+是Objective-C与C+混编的文 件），#include C/C+头文件。 8.写delegate的时候类型应该为weak弱引用，以避免循环引用，

24、当delegate对象不存在后，我们写的delegate也就没有存在意义了自然是需要销毁的，weak与strong可以参考上一篇文章介绍。 9.实例变量声明时变量名前面加下划线“_”，局部变量不用加。  10.使用Block时，内容四个空格缩进，“”后带有参数时，参数与“”之间有一个空格缩进 11.建议使用“#pragma mark”，方便阅读代码属性命名描述性的单词+变量类型 是最好的,一目了然 例如:UILabel* nameLabel;类命名前缀+描述+类型注:前缀可以是你的姓名/昵称等主要用于团队开发的时候避免文件名重复以下是我个人命名方式 例:

25、XJX             - 姓名/昵称Message     - 描述性本类的功能Cell/Model  - 类型/模型方法命名方法使用小驼峰法命名一个规范的方法读起来应该像一句完整的话，读过之后便知函数的作用。执行性的方法应该以动词开头，小写字母开头。返回性的方法应该以返回的内容开头，但之前不要加get。示例：-(void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;-(instancetype)arrayWith

26、Array:(NSArray *)array;常量命名通常与项目设置的类文件前缀相同，跟随其后的命名应采用驼峰命名法则，命名应准确表述常量表示的意义。示例：#define  kRunAnnotationStartPointTitle    “起点"typedefNS_ENUM(NSInteger, UITableViewStyle)     UITableViewStylePlain,        / regular table view    UITableViewSty

27、leGrouped   / preferences style table view;NSString*constUIApplicationLaunchOptionsRemoteNotificationKey;NSString*constUIApplicationLaunchOptionsLocalNotificationKey;图片命名原则：1）采用单词全拼，或者大家公认无岐义的缩写(比如：nav，bg，btn等)2）采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块主要包括统一的背景，导航条，标签，公共的按钮背景，公共的默认图等等；私有模块主要根据app的业务功能模块

28、划分，比如用户中心，消息中心等备注：建议背景图采用以bg作前缀，按钮背景采用btn作前缀（不作强制要求，项目实际负责人根据团队特点确定即可）公共模块命名示例：导航条背影图片：bg_nav_bar2x.png导航返回按钮：bg_nav_back_normal2x.png，bg_nav_back_selected2x.png标签item背景：bg_tabbar_record_normal2x.png，bg_tabbar_record_selected2x.png私有模块命名示例：以土冒APP的首页图片资源为例说明，首页搜索背景图：bg_home_search2x.png首页消息默认背景图：bg_h

29、ome_info_normal2x.png首页消息高亮背景图：bg_home_info_highlight2x.png函数命名如果有参数，函数名应该作为第一个参数的提示信息，若有多个参数，在参数前也应该有提示信息（一般不必加and）一些经典的操作应该使用约定的动词，如initWith,insert,remove,replace,add等等。代码注释提及命名,不得不马上提醒代码的注释问题!很多同事的注释过于粗糙,有些甚至都没有注释习惯,导致代码可读性差,版本迭代或是需求变更的时候不能及时定位到具体代码以下已model类为例:/* 名字 */property(nonatomic,strong)NS

30、String* name;/* 年龄 */property(nonatomic,strong)NSString* age;/* 性别 */property(nonatomic)BOOL sex;注释统一采用文档注释方式:/*  */这样注释的好处是:当你调用这个属性时会具有相关备注提示 例:题外话 - Xcode插件 - VVDocumenter这是一个文档注释插件,可以帮助开发者快速的注释,提高工作效率,这也是本人比较常用的一款插件,具体效果请前往github查看附上github链接:代码组织在函数分组和protocol/delegate实现中使用#pragma mark -来分类方法：#pragma mark - Lifecycle-(id)init- (void)dealloc - (void)viewDidLoad - (void)viewWillAppear:(BO