Swift开发规范

最新推荐文章于 2023-07-11 16:14:01 发布

Coder&Star

最新推荐文章于 2023-07-11 16:14:01 发布

阅读量398

点赞数

文章标签： swift ios

本文链接：https://blog.csdn.net/li_tianxng/article/details/120122977

版权

前言

开发规范的目的是保证统一项目成员的编码风格，并使代码美观，每个公司对于代码的规范也不尽相同，希望该份规范能给大家起到借鉴作用。。

命名规约

代码中的命名严禁使用拼音及英文混合的方式，更不允许直接出现中文的方式，最好也不要使用下划线或者美元符号开头；
文件名、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 修饰