[TOC]

iOS开发规范（beta 1.0.3版）

项目编写要求

-- 写出你能看懂的代码，而不只是机器能读懂的代码。

• 项目采取纯代码编写方式
• 布局采取AutoLayout+Frame（根据设备尺寸等比适配）方式
• 当前系统适配最低iOS 10
• 当前仅支持竖屏布局
• 项目结构采取分功能模块创建文件夹形式
• 模块内全局常量定义可在模块根目录创建模块头文件定义

文件夹

• 所有文件夹均采取实体文件夹存在方式
• 项目文件夹结构采取分模块创建形式，例如主页模块，可命名Home或HomePage，二级目录划分为Controller,Model,View,Data

文件

--
代码文件头部需添加必要的文件信息包括但不限于如下条目：

• 文件名称

• 项目名称

• 版权及著作权信息（可额外添加版权所属个人及单位网址）

• 创建时间

• 如若开源需添加开源协议简要说明或表明可查看同项目下单独的协议文件

Controller结构

#pragma mark -
#pragma mark - 👉Life cycle 👈

#pragma mark -
#pragma mark - 👉 Request 👈

#pragma mark -
#pragma mark - 👉 <#Name#> Delegate 👈

#pragma mark -
#pragma mark - 👉 Event Response 👈 

#pragma mark -
#pragma mark - 👉 Private Methods 👈

#pragma mark -
#pragma mark - 👉 Setter / Getter 👈

#pragma mark -
#pragma mark - 👉 Default Setting / UI / Layout 👈

View结构

#pragma mark -
#pragma mark - 👉  Life cycle 👈

#pragma mark -
#pragma mark - 👉  Public Methods 👈

#pragma mark -
#pragma mark - 👉  <#Name#> Delegate 👈

#pragma mark -
#pragma mark - 👉  Event Response 👈

#pragma mark -
#pragma mark - 👉  Private Methods 👈

#pragma mark -
#pragma mark - 👉  Setter / Getter 👈

#pragma mark -
#pragma mark - 👉  Default Setting / UI / Layout 👈

命名规范

--

• 公共类名需结合项目名称来命名，确保整个项目中的自定义类的名称开头是统一的。

• 模块内类及文件命名需结合功能及模块，采用大驼峰命名法，特有名词可允许当前名词全大写

• 枚举定义命名参见类及文件命名法

• 函数及方法，属性与变量命名需采用小驼峰命名法

• 宏及常量需采用k开头大驼峰命名

• 项目中涉及到的资源（图片，文件等），不可使用汉字命名，尽量使用英文命名，国内特有名词可使用拼音，示例图片命名如下：

store_share_normal@3x
store_share_selected@3x

• 分类命名需结合项目及模块命名，工具类分类可以项目前缀命名如：UIView+DYExtension.h或UIView+DYCategory.h，并加入相关公共组件，相关业务库分类需以业务模块前缀命名如:UIView+DYMineExtension.h或UIView+DYMineCategory.h
• 数据库表名应以统一前缀+模块前缀+表功能描述比如用户信息表dy_user_userinfo
• 分类中自定义方法名应以小写dy+_作为前缀，按小驼峰命名法命名:

示例

```objectivec

- (void)ls_publicMethod{
    //do something
}
```

后缀：

• 控制器以Controller结尾

• 自定义Cell以Cell结尾

• 自定义View以View结尾

• 网络请求实体类以Request结尾

• Block以Block结尾

• Protocol以Protocol结尾

• Delegate以Delegate结尾

以上规范均需符合见文知义之规则

注释规范

--

• 属性及变量，常量，宏等需添加单行注释说明其含义

```objectivec

/**年龄*/
@property (nonatomic, assign) NSInteger age;
```

• 类需添加多行注释

```objectivec

/**
 *    这是个测试类，用于测试
 */
@interface Test : NSObject

@end
```

• 方法需添加详细多行注释，说明方法作用及入参与出参含义

  
    /**
     测试方法
    
     @param string 测试参数
     @return 测试结果
     */
    - (NSString *)test:(NSString *)string;
    
  

• 版本更新迭代导致方法与函数废弃或逐渐废弃需添加废弃说明

    /**
     测试方法
    
     @param string 测试参数
     @return 测试结果
     */
    -(NSString *)test:(NSString *)string DEPRECATED_MSG_ATTRIBUTE("此方法已在2.0版本弃用，请使用替代方法[test1:]");
  
    
  

以上注释均需添加在被注释内容前面，禁止使用行尾注释

书写规范

--

• 分类中尽量不要重写系统方法

• 项目中多次用到的公共方法应抽离出来

• 代码需符合当前开发语言格式化规范，无明确规范默认行首缩进4个空格，方法与函数间空一行

• 多使用断言做代码校验

• 必要的容错处理，特别熟数据解析，try catch做可用性判断防止因赋值及结构等问题导致的crash，并根据需求做日志上传

• 单句代码需含义相同，禁止出现类似if(Obj){return}写法

• 同一行只能声明一个属性或变量

• 网络请求实体类tag值禁止直接使用数字，需定义成常量

• iOS 13及之后系统禁止使用 KVC访问私有API

• 项目中控制台打印日志用DYLog

• 禁止出现包含逻辑的宏定义

• 常量需用const 定义，禁止使用宏定义常量

版本控制规范

--

• 我司代码版本控制采取git管理

• 每个工程需有最少两个远程分支，master分支为稳定版本分支，此分支代码只能从其他分支合并，不能直接修改，并限定操作人员权限，开发阶段代码禁止推送到master，开发阶段远程分支使用dev分支，开发人员可创建个人本地分支，每日提交代码需将本地分支合并至dev后提交，如需其他远程分支譬如fix,beta可结合公司实际情况商讨后决定是否必要,公司项目当前阶段暂不需要，根据项目后期发展变化添加

• 除master，dev等常规分支外，其他功能性分支命名应该体现当前功能

• 每次迭代，主工程需打对应版本tag，tag规范无特殊情况需采取三段式版本规范即x.x.x格式，特殊情况可不遵守三段式规范，采取能体现当时情况tag值，其他模块工程同理，但可不与主工程tag同步

• 每次提交的代码必须编译运行通过，不得出现冲突，报错代码。

• 如果内容有修改每次commit必须书写修改内容简要信息

私有Pod库规范

--

• 详细的创建，推送操作参见 http://git.xuetang.com/iOS_Group/iOS-D/blob/master/pod库创建流程（上）.pdf

其他规范

--

• 项目整体采取MVC模式，也可采取其他模式如MVVM

• 数据持久化需上报并附带说明

• release版本中禁止出现测试阶段代码

• hook系统方法需做备案

• 提交代码前认真检查，本地run一次没问题再提交

• 添加三方类库需申请并在三方库列表做备案,

• 常用的工具方法比如字符串MD5,快速获取视图宽高,时间格式化等DYFoundation和DYKit中已定义大部分，有类似需求可先去相应类库查找，如不满足需求可自行添加并做说明，相关规范参见上文命名规范部分

项目规范

--

• 关于服务器环境，我司分为三个环境，开发，测试和生产，对应环境的切换可通过 DYConfig模块中DYConfigManager 统一配置切换，附DYConfig项目地址 http://git.zhcs.com/iOS_Group/DYConfig.git

• 各模块网络请求url创建单独文件统一管理，以下给出参考做法:

  #if defined(DEBUG) || defined(_DEBUG)
  
  static NSString * const kNewLoginModulePath = @"http://git.xuetang/login/api/v1";
  
  #else
  
  static NSString * const kNewLoginModulePath = @"";
  
  #endif
  
  
  #pragma mark --> 🐷 网络请求 🐷
  /// 密码登录
  static inline NSString *  kLoginPasswordPath(){
      return   [NSString stringWithFormat:@"%@%@",kNewLoginModulePath,@"/user/login/password"];
  }
  
  /// 登出
  static inline NSString *  kNewLogoutPath(){
      return   [NSString stringWithFormat:@"%@%@",kNewLoginModulePath,@"/user/login/logout"];
  }
  

• 各模块需要用到的界面跳转等Router方法等具体参考 http://git.xuetang.com/iOS_Group/LSService 中的方法与demo，url创建文件统一管理维护，一下给出参考做法:

  
  static NSString * const kDYStoreModuleScheme = @"youxuetang://";
  
  
  #pragma mark >_<! 👉🏻 🐷界面跳转URL🐷
  
  /** 商城容器-标签页url */
  static inline NSString * kStoreModule_container_url(){
      return [NSString stringWithFormat:@"%@%@",kDYStoreModuleScheme,@"store/container"];
  }
  
  

• 各模块路由注册部分创建单独的路由注册类统一管理维护，以下给出参考做法：

  
  @implementation DYStoreRouterRegisterTool
  
  
  +(void)load{
      
      //注册商城-标签控制器
       [DYServiceManager registerObjectRouteURL:kStoreModule_container_url() handler:^id(NSDictionary *routerParameters) {
           DYStoreTabbarController * vc = [[DYStoreTabbarController alloc]init];
           return vc;
       }];
      
  
  }
  
  @end
  
  

• 项目中需要用到的用户信息等方法 参考 http://git.xuetang.com/iOS_Group/DYUser 中方法与demo

• 项目开发过程中用到色值设置，统一用kit中提供的公共方法，示例如下:

  
  /**
   蓝色 28a1ff
   
   @return #28a1ff
   */
  + (UIColor *)colorBlue1;
  
  

• 项目开发过程中用到的字体设置，统一用kit中提供的公共方法，示例如下:

  
  /// 字体设置
  /// @param fontType 字体类型
  + (UIFont *)dy_font10pt:(LSFontBoldType)fontType;
  
  

• 项目中用到获取本地图片方法统一用kit中提供的方法，示例如下:

  //如果为本地Images.xcassets中资源图片用如下方法
  
  static inline UIImage *kImageNamed(NSString *name) {
      return [UIImage imageNamed:name];
  }
  
  
  //如果为`DYResources`资源库中存放图片资源用如下方法
  
  static inline UIImage *kIconNamed(NSString *name) {
      return [LSIcon ls_imageNamed:name];
  }
  

规范的目的不在于给编码过程制造障碍，而在于保持<font size = 5 >团队</font>的一致性与后期代码的可维护性，减少上手熟悉时间，增加代码可读性，提高代码可靠性和健壮性，作为一名优秀的工程师，我们应该不断完善并严格遵守代码规范，共勉

未完待续......>_<!