ios开发标准规范文档.doc

命名
命名规则对于维护代码来说是非常重要,。Objective-C办法名往往很长，但是这也有好处，让诸多注释变得毫无意义。
本文推荐驼峰法，也是Objective-C社区原则。 
驼峰法分小驼峰法和大驼峰法。小驼峰法：除第一种单词之外，其她单词首字母大写。大驼峰法相比小驼峰法，大驼峰法把第一种单词首字母也大写了。
1.基本原则
1.1 清晰
又清晰又简洁是最佳了，但简洁不如清晰重要。总讲不要使用单词简写，除了非常惯用简写以外，尽量使用单词全称。API名称不要有歧义，一看你API就懂得是以什么方式做了什么事情，不要让人有疑问
1.2 一致性
做某个事情代码普通都叫这个名字，例如tag、setStringValue，那么你也这样叫。你在不拟定怎么起名字时候，可以参照某些惯用名字：Method Arguments
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. 办法命名 
办法使用小驼峰法命名，一种规范办法读起来应当像一句完整话，读过之后便知函数
作用。执行性办法应当以动词开头，小写字母开头，返回性办法应当以返回内容
开头，但之前不要加get。
示例：
- (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;
(instancetype)arrayWithArray:(NSArray *)array;

如果有参数，函数名应当作为第一种参数提示信息，若有各种参数，在参数前也应当有
提示信息（普通不必加and）
 某些典型操作应当使用商定动词，如initWith,insert,remove,replace,add等等。
5. 变量命名 
变量名使用小驼峰法，使变量名尽量可以推测其用途属性具备描述性。别一心想着少打几
个字母，让你代码可以迅速被理解更加重要。
5.1 类成员变量：
成员变量用小驼峰法命名并前缀下划线，Objective-C 2.0，@property 和 @synthesize 提供
了遵守命名规范解决办法

示例：
@interface ViewController ()
@property (nonatomic,strong)NSMutableArray    *mDataArray;
@property (nonatomic,strong)UITableView       *mtableView;
@end

@implementation ViewController

@end

5.2 普通变量命名 

示例：

NSMutableArray  *ticketsArray = [NSMutableArrayarrayWithCapacity:0]；   
NSInteger numCompletedConnections =3;

5.3 常量命名 

常量(预定义，枚举，局部常量等)使用小写k开头驼峰法，例如kInvalidHandle , 
kWritePerm 

示例：
#define kRunAnnotationStartPointTitle     @“起点"

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作前缀（不作强制规定，项目实际
负责人依照团队特点拟定即可）

公共模块命名示例：
导航条背影图片：
导航返回按钮：，
标签item背景：，

私有模块命名示例：
以Joggers APP顾客中心图片资源为例阐明，
uc——user center
顾客中心头像默认图：
顾客中心顶部默认背景图：
顾客中心底部背景图：

这某些工作较为繁杂，并且在程序员心中会以为是技术含量较低一种工作，但图片命名
严谨性同样会反映出咱们对细节追求，细节决定成败。
文献组织构造
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生命周期函数放到最上面，自己实现办法在下面，相似/相近功能办法采用#pragma mark -来标记，以便查看。
示例：

  第一某些重要对易把握，易推广，并且对团队开发中有实实在在协助内容作简要阐述，重要集中在命名，文献组织原则方面，并给了相应示例。规范由各项目负责人详细执行。好像忘掉一件什么事，没错，注释，上述没有对注释做专门阐述，良好代码习惯就是一种好注释，因而这里不专门为注释作讨论，注释规定由各项目负责人来商定。

团队规定
iOS代码规范

1 删除多余空行
     * 所有办法与办法之间空1行
     * 所有代码块之间空1行
2 删除多余注释
     * 删除注释掉代码
     * 删除没故意义注释
3 删除多余办法
     * 如果办法没有使用到，请删除它
     * 如果办法没有执行任何业务逻辑，请删除它或者给出一定注释
4 删除未被使用资源文献
5 添加必要注释
     * 所有 .h 文献中property 需要给出注释
     * 所有自定义办法需要给出注释
     * 比较大代码块需要给出注释
     * 所有代码中浮现阿拉伯数字需要给出注释
     * 程序中浮现加密／解密 逻辑操作地方，需要给出注释阐明过程（无论是系统还是自定义）
6 整体代码风格需要统一
     * 代码背面”{“ 不需要单独占用一行
     * 逻辑运算符 与 代码之前空一格
     * “#pragma mark -” 与下面代码之前不要空行
     * 遵循普通性代码规范

iOS通用规则

1 下面所有规则对第三方类库无约束
     * 所有类、办法、属性等命名，做到见名知意，采用驼峰式命名规则
     * 依照资源类型或者所属业务逻辑对项目资源进行分组，使得整个项目构造清晰明了
     * 整个项目保持一种代码书写风格（这个风格由无锡团队依照自己编码习惯来定），让你代码变优雅！
2. 命名规范
     * 所有类名称以项目工程开头命名，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. 请多使用 #pragma mark - Mark Name 对办法进行分组 eg:
     * #pragma mark - View lifeCycle
     * #pragma mark - View lifeTerm
     * #pragma mark - Init methods
     * #pragma mark - Action methods
     * #pragma mark - Common methods
     * #pragma mark - UIActionSheetDelegate
     * #pragma mark - UIImagePickerControllerDelegate
     * #pragma mark - UITableViewDelegate Methods
     * #pragma mark - UITableViewDataSource Methods
     * #pragma mark - UIScrollViewDelegate Methods
     * #pragma mark - UITextFieldDelegate Methods
     * #pragma mark - UITextViewDelegate Methods 

1.代码行度最大为100列

2.声明类或办法时，注意空格使用，参数过多时可换行保持对齐，

调用办法时也是如此，参数都写在一行或换行冒号对齐，

3.命名规则   

类名首字母大写，办法首字母小写，办法中参数首字母小写，同步尽量让办法命名读起来像一句话，可以传达出办法意思，同步取值办法前不要加前缀“get”

变量名小写字母开头

常量以小写字母k开头，后续首字母大写

4.关于注释

注释很重要，但除了开头版权声明，尽量把代码写犹如文档同样，让别人直接看代码就懂得意思，写代码时别紧张名字太长，相信Xcode提示功能。

5.实例变量应当在实现文献.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弱引用，以避免循环引用，当delegate对象不存在后，咱们写delegate也就没有存在乎义了自然是需要销毁，weak与strong可以参照上一篇文章简介。

9.实例变量声明时变量名前面加下划线“_”，局部变量不用加。

10.使用Block时，内容四个空格缩进，“^”后带有参数时，参数与“{”之间有一种空格缩进

11.建议使用“#pragma mark”，以便阅读代码

属性命名
描述性单词+变量类型 是最佳,一目了然 例如:
UILabel* nameLabel;
类命名
前缀+描述+类型
注:前缀可以是你姓名/昵称等重要用于团队开发时候避免文献名重复
如下是我个人命名方式 例:
XJX             --- 姓名/昵称
Message     --- 描述性本类功能
Cell/Model  --- 类型/模型

办法命名
办法使用小驼峰法命名
一种规范办法读起来应当像一句完整话，读过之后便知函数作用。执行性办法应当以动词开头，小写字母开头。返回性办法应当以返回内容开头，但之前不要加get。
示例：
-(void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;
-(instancetype)arrayWithArray:(NSArray *)array;
常量命名
普通与项目设立类文献前缀相似，跟随其后命名应采用驼峰命名法则，命名应精确表述常量表达意义。
示例：
#define  kRunAnnotationStartPointTitle    @“起点"
typedefNS_ENUM(NSInteger，UITableViewStyle) {
    UITableViewStylePlain，       // regular table view
    UITableViewStyleGrouped   // preferences style table view
};
NSString*constUIApplicationLaunchOptionsRemoteNotificationKey;
NSString*constUIApplicationLaunchOptionsLocalNotificationKey;
图片命名
原则：
1）采用单词全拼，或者人们公认无岐义缩写(例如：nav，bg，btn等)
2）采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块重要涉及统一背
景，导航条，标签，公共按钮背景，公共默认图等等；私有模块重要依照app业务
功能模块划分，例如顾客中心，消息中心等
备注：建议背景图采用以bg作前缀，按钮背景采用btn作前缀（不作强制规定，项目实际
负责人依照团队特点拟定即可）
公共模块命名示例：
导航条背影图片：
导航返回按钮：，
标签item背景：，
私有模块命名示例：
以土冒APP首页图片资源为例阐明，
首页搜索背景图：
首页消息默认背景图：
首页消息高亮背景图：
函数命名
如果有参数，函数名应当作为第一种参数提示信息若有各种参数，在参数前也应当有提示信息（普通不必加and）
某些典型操作应当使用商定动词，如initWith,insert,remove,replace,add等等。
代码注释
提及命名,不得不立即提示代码注释问题!诸多同事注释过于粗糙,有些甚至都没有注释习惯,导致代码可读性差,版本迭代或是需求变更时候不能及时定位到详细代码
如下已model类为例:
/** 名字 */
@property(nonatomic,strong)NSString* 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:(BOOL)animated {}
- (void)didReceiveMemoryWarning {}
#pragma mark - Custom Accessors
- (void)setUpTableView{}
#pragma mark - IBActions
- (IBAction)submitData:(id)sender {}
#pragma mark - Public
- (void)publicMethod {}
#pragma mark - Private
- (void)privateMethod {}
#pragma mark - Protocol conformance
#pragma mark - UITextFieldDelegate
#pragma mark - UITableViewDataSource
#pragma mark - UITableViewDelegate
#pragma mark - NSCopying
- (id)copyWithZone:(NSZone*)zone {}
#pragma mark - NSObject
- (NSString*)description {}
有人也许不明白这种注释好处,上两张对比图人们可以直观感觉一下
未注释

注释

作用
告诉Xcode编译器,要在编译器窗格顶部办法和函数弹出菜单中将代码分隔开.
某些类(特别是某些控制器类)也许代码量非常大,办法和函数弹出菜单可以便于代码导航.此时加入#pragma 指令对代码进行逻辑组织就显得非常有效果
黄金途径
当使用条件语句编码时，左手边代码应当是"golden" 或 "happy"途径。也就是不要嵌套if语句，各种返回语句也是OK。
应当:
- (void)someMethod {
    if(![someOther boolValue]) {
        return;  
    }
    //Do something important
}
不应当
- (void)someMethod {
    if([someOther boolValue]) {
       //Do something important
    }
}