iOS开发规范文档

iOS 开发规范 命名命名 本文推荐驼峰法 也是 Objective C 社区的标准 驼峰法分小驼峰法和大驼峰法 小驼峰法 除第一个单词之外 其他单词首字母大写 大 驼峰法相比小驼峰法 大驼峰法把第一个单词的首字母也大写了 2 类命名类命名 类名 不包括类别和协议名 应该用大写开头的大驼峰命名法 类名中应该包含一个或多个 名词来说明这个类 或者类的对象 是做什么的 在应用级别的代码里 尽量不要使用带前缀的类名 每个类都有相同的前缀不能提高可读 性 不过如果是编写多个应用间的共享代码 前缀就是可接受并推荐的做法了 型如 JKPhotoBrowser 示例 1 interface ImageBrowseView UIView end 示例 2 带前缀 JK interface JKPhotoBrowser 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 dataArray property nonatomic strong UITableView tableView 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 作前缀 不作强制要求 项目实际 负责人根据团队特点确定即可 公共模块命名示例 导航条背影图片 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 类文件组织 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