前言

开发规范的目的是保证统一项目成员的编码风格，并使代码美观，每个公司对于代码的规范也不尽相同，希望该份规范能给大家起到借鉴作用。本文为原创，如需转载请说明原文地址链接。

命名规约

• 代码中的命名严禁使用拼音及英文混合的方式，更不允许直接出现中文的方式，最好也不要使用下划线或者美元符号开头；
• 文件名、class、struct、enum、protocol 命名统一使用 UpperCamelCase 风格；
• 方法名、参数名、成员变量、局部变量、枚举成员统一使用 lowerCamelCase 风格
• 全局常量命名使用 k 前缀 + UpperCamelCase 命名；
• 扩展文件，用“原始类型名＋扩展名”作为扩展文件名，其中原始类型名及扩展名也使用 UpperCamelCase 风格，如UIView+Frame.swift；
• 工程中文件夹或者 Group 统一使用 UpperCamelCase 风格，一律使用单数形式；
• 命名中出现缩略词时，缩略词要么全部大写，要么全部小写，以首字母大小写为准，通用缩略词包括 JSON、URL 等；如class IDUtil {}、func idToString() { }
• 不要使用不规范的缩写，如 AbstractClass“缩写”命名成 AbsClass 等，不怕名称长，就怕名称不明确。
• 文件名如果有复数含义，文件名应使用复数形式，如一些工具类；

修饰规约

• 能用 let 修饰的时候，不要使用 var；
• 修饰符顺序按照 注解、访问限制、static、final 顺序；
• 尽可能利用访问限制修饰符控制类、方法等的访问限制；
• 写方法时，要考虑这个方法是否会被重载。如果不会，标记为 final，final 会缩短编译时间；
• 在编写库的时候需要注意修饰符的选用，遵循开闭原则；

格式规约

• 类、函数左大括号不另起一行，与名称之间留有空格
• 禁止使用无用分号
• 代码中的空格出现地点
  • 注释符号与注释内容之间有空格
  • 类继承, 参数名和类型之间等, 冒号前面不加空格, 但后面跟空格
  • 任何运算符前后有空格
  • 表示返回值的 -> 两边
  • 参数列表、数组、tuple、字典里的逗号后面有一个空格
• 方法之间空一行
• 重载的声明放在一起，按照参数的多少从少到多向下排列
• 每一行只声明一个变量
• 如果是一个很长的数字时，建议使用下划线按照语言习惯三位或者四位一组分割连接。
• 表示单例的静态属性，一般命名为 shared 或者 default
• 如果是空的 block，直接声明{ }，括号之间不需换行
• 解包时推荐使用原有名字，前提是解包后的名字与解包前的名字在作用域上不会形成冲突
• if 后面的 else\else if, 跟着上一个 if\else if 的右括号
• switch 中, case 跟 switch 左对齐
• 每行代码长度应小于 100 个字符，或者阅读时候不应该需要滚动屏幕，在正常范围内可以看到完整代码
• 实现每个协议时, 在单独的 extension 里来实现

简略规约

• Swift 会被结构体按照自身的成员自动生成一个非 public 的初始化方法，如果这个初始化方法刚好适合，不要自己再声明
• 类及结构体初始化方法不要直接调用.init，直接直接省略，使用()
• 如果只有一个 get 的计算属性，忽略 get
• 数据定义时，尽量使用字面量形式进行自动推断，如果上下文不足以推断字面量类型时，需要声明赋值类型
• 省略默认的访问权限（internal）
• 过滤, 转换等, 优先使用 filter, map 等高阶函数简化代码，并尽量使用最简写
• 使用闭包时，尽量使用最简写
• 使用枚举属性时尽量使用自动推断，进行缩写
• 无用的代码及时删除
• 尽量使用各种语法糖
• 访问实例成员或方法时尽量不要使用 self.，特殊场景除外，如构造函数时
• 当方法无返回值时，不需添加 void

注释规约

• 文档注释使用单行注释，即///，不使用多行注释，即/***/。 多行注释用于对某一代码段或者设计进行描述
• 对于公开的类、方法以及属性等必须加上文档注释，方法需要加上对应的Parameter（s）、Returns、Throws 标签，强烈建议使用⌥ ⌘ /自动生成文档模板
• 在代码中灵活的使用一些地标注释，如MARK、FIXME、TODO，当同一文件中存在多种类型定义或者多种逻辑时，可以使用Mark进行分组注释
• 尽量将注释另起一行，而不是放在代码后

其他

• 不要使用魔法值(即未经定义的常量)；
• 函数参数最多不得超过 8 个；寄存器数目问题，超过 8 个会影响效率；
• 图形化的字面量，#colorLiteral(...), #imageLiteral(...)只能用在 playground 当做自我练习使用，禁止在项目工程中使用
• 避免强制解包以及强制类型映射，尽量使用if let 或 guard let进行解包，禁止try！形式处理异常，避免使用隐式解包
• 避免判断语句嵌套层次太深，使用 guard 提前返回
• 如果 for 循环在函数体中只有一个 if 判断，使用 for where 进行替换
• 实现每个协议时, 尽量在单独的 extension 里来实现；但需要考虑到协议的方法是否有 override 的可能，定义在 extension 的方法无法被 override，除非加上@objc 方法修改其派发方式
• 优先创建函数而不是自定义操作符
• 尽可能少的使用全局命名空间，如常量、变量、方法等
• 赋值数组、字典时每个元素分别占用一行时，最后一个选项后面也添加逗号；这样未来如果有元素加入会更加方便
• 布尔类型属性使用 is 作为属性名前缀，返回值为布尔型类型的方法名使用 is 作为方法名作为前缀
• 类似注解的修饰词单独占一行，如@objc，@discardableResult 等
• extension 上不用加任何修饰符，修饰符加在 extension 内的变量或方法上
• 使用 guard 来提前结束条件，避免形成判断嵌套；
• 善用字典去减少判断，可将条件与结果分别当做 key 及 value 存入字典中；
• 封装时善用 assert，方便问题排查；
• 在闭包中使用 self 时使用捕获列表[weak self]避免循环引用，闭包开始判断 self 的有效性
• 使用委托和协议时，避免循环引用，定义属性的时候使用 weak 修饰

工具

SwiftLint 工具 提示格式错误

SwiftFormat 工具 提示并修复格式错误

两者大部分格式规范都是一致的，少许规范不一致，两个工具之间使用不冲突，可以在项目中共存。我们通过配置文件可以控制启用或者关闭相应的规则，具体使用规则参照对应仓库的 REAMME.md 文件。

相关规范

Swift 官方 API 设计指南

google 发布的 Swift 编码规范

有一个技术的圈子与一群同道众人非常重要，来我的技术公众号及博客，这里只聊技术干货。

• 微信公众号：CoderStar
• 博客：CoderStar's Blog

链接：https://juejin.cn/post/6976282985695969294