iOS 开发框架规范

 

一.命名规范

小驼峰命名法：第一个单字以小写字母开始；第二个单字的首字母大写，如：testClass
大驼峰命名法：每一个单字的首字母都采用大写字母，如：
TestClass
类命名：
首字母大写，之后每个单词首字母都大写
使用能够反映类功能的名词短语
文件和类同名
举例：BaseClient .h、ImageStore .h

特殊类命名
如果是视图控制器的子类应添加后缀“ViewController”或者“Controller”
如果是视图的子类应添加后缀“View”
如果是按钮的子类应添加后缀“Button”
等……
举例：SettingsViewController、NavigationView

分类（类别）命名
与类命名相同，此外需添加要扩展的类名和“+”
举例：NSString+URLEncoding

协议（委托）命名
与类命名相同，此外需添加“Delegate”后缀
举例：ReplyViewDelegate

方法命名
首字母小写，之后每个单词首字母都大写
方法名使用动词短语
举例：- (void)setPostValue:(int)value

方法参数命名
首字母小写，之后每个单词首字母都大写
具有足够的说明性
不需要添加类型前缀
举例：- (void)sendUserInfo:(NSDictionary *)userInfo

常量
常量（宏定义，局部常量等）使用小写k开头的驼峰法
举例：kInvalidHandle , kWritePerm

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

分组命名
使用英文，首字母大写，之后每个单词首字母都大写

图片资源命名方式，以功能为组织形式，是一个很好的习惯，有利于查看资源文件。

原则：

采用单词全拼，或者大家公认无岐义的缩写(比如：nav，bg，btn等)
采用“模块+功能”命名法，模块分为公共模块、私有模块。公共模块主要包括统一的背景，导航条，标签，公共的按钮背景，公共的默认图等等；私有模块主要根据app的业务
功能模块划分，比如用户中心，消息中心等
备注：建议背景图采用以bg作前缀，按钮背景采用btn作前缀（不作强制要求，项目实际负责人根据团队特点确定即可）

公共模块命名示例：

导航条背影图片：bg_nav_bar@2x.png

导航返回按钮：bg_nav_back_normal@2x.png，
bg_nav_back_selected@2x.png

标签item背景：bg_tabbar_record_normal@2x.png，bg_tabbar_record_selected@2x.png

私有模块命名示例：

以Joggers APP的用户中心图片资源为例说明，
uc——user center+

用户中心头像默认图：bg_uc_avatar@2x.png

用户中心顶部默认背景图：bg_uc_top_defaut@2x.png

用户中心底部背景图：bg_uc_bottom@2x.png

 

二.目录结构

1.主目录结构
-Demo
    --AppDelegate         // 程序入口
    --Class               // 业务模块。
    --FunctionModule      // 功能模块  
      ---Manager          // 管理类。账号管理等
      ---Utility          // 工具类。HUD,AlertView等
    --BasicModule         //  基础模块
      ---Config           // 初始化配置。包含宏定义文件，全局配置文件，全局常量文件  
      ---Category         // 类目。包含各种类的分类
      ---BaseVC           //基础VC
      ---BaseView         //基础View
      ---BaseModel        //基础Model
    --Resource            // 资源。包含plist,image,html,bundle，Localizable.strings等
      ---Vendors          // 第三方库。部分需要修改或者不支持cocoapod的第三方的框架引入

-Demo Tests
-Demo UITests
-Products                 // 系统自动生成的.app所在文件夹
-Pods                     // 采用 CocoaPods 管理的第三方库。

2.模块目录结构
-- Class         
    ---Base               // model view和VC个数超过两个以上必须用文件夹
        ----VC     
        ----Model       
        ----View 
    ---Home
        ----VC     
        ----Model       
        ----View 
    类推...

三.代码结构

#pragma mark - Life Cycle Methods
- (instancetype)init
- (void)dealloc

- (void)viewWillAppear:(BOOL)animated
- (void)viewDidAppear:(BOOL)animated
- (void)viewWillDisappear:(BOOL)animated
- (void)viewDidDisappear:(BOOL)animated

#pragma mark - Override Methods

#pragma mark - Intial Methods

#pragma mark - Network Methods

#pragma mark - Target Methods

#pragma mark - Public Methods

#pragma mark - Private Methods

#pragma mark - UITableViewDataSource  
#pragma mark - UITableViewDelegate  

#pragma mark - Lazy Loads

#pragma mark - NSCopying  

#pragma mark - NSObject  Methods

四.代码注释

一、几种不同的注释方式
注释的作用这里就不用赘述了，在项目中，不建议到处写注释，好的代码应该是用代码就可以说话的，比如见名就知意的变量名、属性名、方法名，比如把做某一项任务的功能单独放一块等。在这里总结一些自己项目中常用的注释。首先我把自己已知的注释方式分为下面几种：
1，单行注释（双杠注释）：双斜杠//，格式：// 注释内容。
2，三杠注释：///，格式：/// 注释内容。
3，多行注释：/**/，格式：/* 注释内容 */。
4，多行注释扩展版本：/**< 注释内容 */、/**> 注释内容 */
二、注释的使用
单行注释在一个文档的任何位置都可以添加，多行注释主要用于对文档介绍和方法的具体描述。当然多行注释也常用于实例变量、属性、方法前注释，主要目的是为了开发维护和在调用的地方能够快速查看这个实例变量、属性、方法的注释描述。三杠注释跟多行注释作用一样。下面列举三杠注释和多行注释的常见使用场景。
1， 实例变量、属性、枚举注释
/// 注释内容和/* 注释内容 */放在实例变量、属性、方法的前一行，/**< 注释内容 */放在实例变量、属性、方法的同一行，在调用的地方查看实例变量、属性、方法的注释时结果是一样的。/**> 注释内容 */表示注释当前行的下一行内容。
之所以列举出三种，是为了让我们根据实际应用场合有不同的选择。比如在枚举注释和实例变量前建议使用/**< 注释内容 */方式。
2，方法注释
Xcode 8.0 之前，快速给方法添加注释我们一般用VVDocument插件，只需连按三个///即可快速添加注释。Xcode 8.0 之后， Xcode内置了快速添加注释的功能，只需按Command + Option + /。
3，方法集注释
#pragma mark - 注释内容(查看时带分割线)
#pragma mark 注释内容(查看时不带分割线)

注释中常用的标签：
@brief : 使用它来写一段你正在文档化的method, PRoperty, class, file, struct, 或enum的短描述信息。
@discusstion: 用它来写一段详尽的描述。如果需要你可以添加换行。
@param:通过它你可以描述一个 method 或 function的参数信息。你可以使用多个这种标签。
@return: 用它来制定一个 method 或 function的返回值。
@note:注意点,补充说明
@see: 用它来指明其他相关的 method 或 function。你可以使用多个这种标签。
@sa:同上
@code ： 使用这个标签，你可以在文档当中嵌入代码段。当在Help Inspector当中查看文档时，代码通过在一个特别的盒子中用一种不同的字体来展示。始终记住在写的代码结尾处使用@endcode标签。
@remark : 在写文档时，用它来强调任何关于代码的特殊之处。
记录文件常用标签：
@file: 使用这个标签来指出你正在记录一个文件（header 文件或不是）。如果你将使用Doxygen来输出文档，那么你最好在这个标签后面紧接着写上文件名字。它是一个top level 标签。
@header: 跟上面的类似，但是是在 HeaderDoc中使用。当你不使用 Doxygen时，不要使用上面的标签。
@author：用它来写下这个文件的创建者信息
@copyright: 添加版权信息
@version: 用它来写下这个文件的当前版本。如果在工程生命周期中版本信息有影响时这会很重要。
@class: 用它来指定一个class的注释文档块的开头。它是一个top level标签，在它后面应该给出class名字。
@interface: 同上
@protocol: 同上两个一样，只是针对protocols
@superclass: 当前class的superclass
@classdesign: 用这个标签来指出你为当前class使用的任何特殊设计模式（例如，你可以提到这个class是不是单例模式或者类似其它的模式）。
@coclass: 与当前class合作的另外一个class的名字。
@helps: 当前class帮助的class的名字。
@helper: 帮助当前class的class名字。

五.第三方使用

1.能用cocoapod 的尽量用cocoapod，这样方便做第三方的依赖管理

2.第三方使用，除了一些特殊类其他的尽量对其进行二次封装，项目不直接使用而是使用二次封装类，这样可以降低更换第三方的代价

3.部分冷门的第三方请说明在文档中写明是用来干什么的并附上相关git链接和自己能找到的相关使用文档链接

六.Git使用

1.注意每次提交都要记得先pull再push注意冲突（如果和别人的项目有冲突的地方请事先和冲突方沟通来决定是否覆盖）

2.记得忽略上传问题，cocoapod只上传链接文档不上传文件，降低仓库占用 和防止仓库冲突，记得同意cocoapod版本

3.记得git 100M上传文件限制，除pod的第三方，其他的直接添加的第三方如果因为文件太大无法上传请在文档中说明且留下相关信息（用处，下载链接）