开发命名规范与框架架构

一、基本规则

1、代码清晰

又清晰又简洁的代码当然是最好的了，但简洁不如清晰重要。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。API的名称不要有歧义，一看你的API就知道是以什么方式做了什么事情，不要让人有疑问！

2、一致性

代码保持一致，例如：创建UI相关的方法,可以使用统一的方法命名，所见即所得，见表知其意，这样，既保证了代码的一致性，也可以方便我们后续维护和管理，也利于团队代码风格的一致，协调！

二、命名规则

1、类命名

小驼峰命名法：

第一个单字以小写字母开始；第二个单字的首字母大写，如：testClass 大驼峰命名法：每一个单字的首字母都采用大写字母，如： TestClass 类命名：

首字母大写，之后每个单词首字母都大写 使用能够反映类功能的名词短语 文件和类同名 举例：BaseClient .h、ImageStore .h。

所有类名、枚举、结构、protocol定义时最好加一个统一的标示符，可以是项目缩写，或者个人项目的名称缩写，例如都加上全大写的Hoo（我的姓氏）作为前缀

1.1、特殊类命名

(1)、所有的控制器都加上Controller,所有的通知名都加上Notification。

(2)、根据功能模块可以在给功能模块的类添加功能模块的名称前缀，如用户中心的profileViewController.可以命名为HooUCProfileViewController.

1.2、分类（类别）命名

与类命名相同，此外需添加要扩展的类名和“+”

举例：NSString+URLEncoding

3、协议（委托）命名

与类命名相同，此外需添加“Delegate”后缀

举例：ReplyViewDelegate

2、方法命名

2.1、首字母小写，之后每个单词首字母都大写

方法名使用动词短语

举例：- (void)setPostValue:(int)value

执行性的方法应该以动词开头，小写字母开头，返回性的方法应该以返回的内容开头，但之前不要加get

- (void)insertModel:(id)model atIndex:(NSUInteger)atIndex;

- (instancetype)arrayWithArray:(NSArray *)array;

2.2、方法参数命名

首字母小写，之后每个单词首字母都大写，具有足够的说明性。不需要添加类型前缀

举例：- (void)sendUserInfo:(NSDictionary *)userInfo

三、属性

变量名使用小驼峰法, 使变量名尽量可以推测其用途属性具有描述性。别一心想着少打几个字母，让你的代码可以迅速被理解更加重要。每个属性命名都加上类型后缀，如，按钮就加上Button后缀，模型就加上Model后缀。

@property (nonatomic, strong) UIButton *submitButton;

1）类成员变量名

　　成员变量用小驼峰法命名并前缀下划线，如:UIButton *_submitButton;

2）局部变量名

　　遵守小驼峰命名规则，如：NSInteger numCompletedConnections =3;

四、枚举、宏定义

枚举类型命名首字母大写，之后每个单词首字母都大写，最后加“s” 枚举变量使用枚举类型去掉“s”作为前缀，每个单词首字母大写，中间不允许加下划线 举例：

typedef enum UIControlEvents{

UIControlEventTouchDown,

UIControlEventTouchUpInside

}UIControlEvents;

以小写k开头，后面单词首字母大写，其余小写。如：

const float kMaxHeigt = 100.0f;

如果是特殊含义的常量也建议加上后缀，如通知加上Notification为后缀，如：

extern Nsstring * Const kLoginSuccessNotification

三、类注释规范

1、类的声明：

/** 类信息。此注释用在类声明的开头。

@class

@abstract 这里可以写关于这个类的一些描述。 */

示例1：

/** 类信息。此注释用在类声明的开头。

@TestClass

@这是一个测试类 */

@interface TestClass :UIView

@end

2、变量的声明

/** @property property的相关注释。

@abstract 这里可以写关于这个Property的一些基本描述。 */

示例2：

/** * name:这是一个名字； */

@property (nonatomic,copy) NSString * name;

3、方法的声明

/** @method 函数(方法)的相关注释。

@abstract 这里可以写一些关于这个方法的一些简要描述

@discussion 这里可以具体写写这个方法如何使用，注意点之类的。 如果你是设计一个抽象类或者一个共通类给给其他类继承的话，建议在这里具体描述一下怎样使用这个方法。

@param text 文字(这里把这个方法需要的参数列出来)

@param error 错误参照

@result 返回结果 */

示例3：

/** * 这是个请求数据方法；

* result : (NSObject*) 数据返回结果；

* block :( doBlock)block 代码块，返回结果需要完成的事； */

-(void)doRequestResult:(NSObject*)result andSuccessBlock:(doBlock)block ;

四、文件组织形式

1、类文件组织

iOS工程文件结构分物理结构和逻辑结构，建议逻辑结构和物理结构保持一致，以便方便有效地管理类文件。 类文件组织要遵循以下两大原则： 基于MVC设计模式原则，至少要保证controller与数据处理，网络请求相对独立 基于功能模块原则，功能模块分包括数据/网络处理，UI前端界面两部分，数据/网络处理应该在数据/网络处理的框架下， 而UI前端界面比如用户中心，消息中心，它们的专有的controller，view等应该在属于文件夹。 还会遇到一些公共的view，可以开辟出公共的文件夹来管理。 在实际中使用中，项目实际负责人可以结合项目特点灵活使用， 但基本的原则一定要保持，保持良好的类文件组织结构，对团队有益无害。

2、图片资源文件组织形式

图片资源文件，强烈建议采用Images.xcassets管理， 尽量少用自己创建的文件夹管理。 使用Images.xcassets的优势很多，具体可以查阅读相关文献资料，这里只从工程管理上说一点，在Images.xcassets中添加图片资源， 不会对project文件造成改变，而直接在文件夹里添加图片文件，每次都会对project文件造成改变， 因此使用Images.xcassets管理图片资源可以减少project冲突的次数

五、代码规范

1、团队规范

说明：一个好的团队，理所当然有其严格的代码规范，好的代码不仅可以提高团队的开放效率，也更利于团队项目的后期维护，统一的代码风格，也是团队的核心，所以规范代码很有必要！ **

1.1、删除多余的空行 所有方法与方法之间空1行 所有代码块之间空1行

1.2、删除多余的注释 删除注释掉的代码 删除没有意义的注释

1.3、删除多余的方法 如果方法没有使用到，请删除它 如果方法没有执行任何业务逻辑，请删除它或者给出一定注释

1.4、删除未被使用的资源文件

1.5、添加必要的注释 所有.h 文件中的property 需要给出注释 所有自定义的方法需要给出注释 比较大的代码块需要给出注释 所有代码中出现的阿拉伯数字需要给出注释 程序中出现加密／解密 逻辑的操作地方，需要给出注释说明过程（无论是系统还是自定义）

1.6、整体代码风格需要统一 代码后面的”{“ 不需要单独占用一行 逻辑运算符 与 代码之前空一格 “#pragma mark -” 与下面的代码之前不要空行 遵循一般性的代码规范

2、iOS通用规范

2.1、下面所有规则对第三方类库无约束

* 所有类、方法、属性等命名，做到见名知意，采用驼峰式命名规则

* 根据资源类型或者所属业务逻辑对项目资源进行分组，使得整个项目结构清晰明了

* 整个项目保持一种代码书写风格（这个风格由团队根据自己编码习惯来定），让你的代码变的优雅！

2.2、命名规范

* 所有类名称以项目工程开头命名，：“QMX”、“SX”、“CS”,”PF”等···；

* 针对不同视图控制器，在末尾添加后缀，

* 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 对方法进行分组

六、架构设计

1、目录结构

WorkPlace:

--Base //项目主项目

----Base //核心框架主目录

------Resource //常用的资源目录，包括图片、声音、xml文档、样式和数据

------Components //常用组件（自定义控件）以及所有控件核心基类

------Config //常用的宏命令以及语言部分。。

------Entity //实体类基类

------Network //与webservice交互的、本地数据库的以及业务基类

------Util //常用的工具类（包含神器、网络图片、xml、soap、form、崩溃报告）

------Supporting Files //配置文件以及，appDelegate基类，用于加载基础数据

----APP //项目主目录

------Components //组件目录，所有的组件（自定义控件）均放在此处

------Resource //资源目录，包括图片、声音、xml文档、样式和数据

------Cell //各种可重用的元素目录，一般包括UITableViewCell子类和UICollectionViewCell子类

------Entity //实体类目录，包括Coredata产生的实体和自定义的实体类

------ShareHandle //单例目录

------Viewcontroller //视图控制器目录

------CustomUtil //配置文件，一般存放用户信息等本地化数据

------Service //业务请求文件，所有的业务请求，包括本地数据库、Webservice等

------Config //配置文件

------AppDelegate //应用程序启动文件

------Basexcdatamodeld //数据库模型文件

----BaseTests //测试主目录

----Framework //IOS的类库框架

----Prouducts //编译出来的archive

--Pods //pods，所有的开源代码包管理工具，便于开发者快速导入开源插件

2、开发库介绍

2.1、网络处理：ASIHttpRequest/AFNetworking

2.2、数据库处理：MagicalRecord

2.3、Socket处理：CocoaAsyncSocket

2.4、拼音转换：PinYin4Objc

2.5、加载插件：MBProgressHUD

2.6、评论提醒：Appirater

2.7、表单切换：TPKeyboardAvoiding

2.8、crash采集：KSCrash

2.9、界面解析：Reveal

2.10、图片缓存：SDWebImage/YYImage

3、Xcode插件使用

3.1、cocoapods 源码包管理工具

3.2、KSImageNamed 图片提示

3.3、VVDocumenter 注释生成

3.4、OMColorSense 颜色显示

3.5、FuzzyAutocomplete 代码提示

3.6、Peckham 头文件补全

3.7、GitDiff 文件改变比较

4、常用工具使用

4.1、Cornerstone SVN源码版本管理工具

4.2、WireShark 网络协议分析

4.3、Doxygen 文档生成工具

4.4、Dash API查询工具

4.5、Reveal 界面结构分析工具

4.6、PaintCode 绘图生成代码工具

4.7、Prepo 图片批量处理工具

4.8、Liya 数据库查看工具

4.9、VisualJson json快速查看工具

4.10、echo 网络API测试工具

4.11、Apns Pusher Apns证书测试工具

4.12、idaq 动态反编译工具

4.13、Pxcook快速标注工具

4.14、sqlitManager数据库查看工具

原文地址：https://www.jianshu.com/p/c680906c3b87