Swift 编码规范
Swift 编码规范
按大概的先后顺序,本文尝试做到以下几点:
- 增进精确,减少程序员犯错的可能
- 明确意图
- 减少冗余
- 减少关于美的争论
如果你有什么建议,请看我们的 贡献导引,然后开个 pull request
. ⚡️
留空白
- 用 tab,而非 空格
- 文件结束时留一空行
- 用足够的空行把代码分割成合理的块
- 不要在一行结尾留下空白
- 千万别在空行留下缩进
能用 let
尽量用 let
而不是 var
尽可能的用 let foo = ...
而不是 var foo = ...
(并且包括你疑惑的时候)。万不得已的时候,再用 var
(就是说:你 知道 这个值会改变,比如:有 weak
修饰的存储变量)。 理由: 这俩关键字 无论意图还是意义 都很清楚了,但是 let
可以产生安全清晰的代码。
let
保障它的值的永远不会变,对程序猿也是个 清晰的标记。因此对于它的用法,之后的代码可以做个强而有力的推断。 理解代码也更容易了。不然一旦你用了 var
,还要去推测值会不会变,这时候你就不得不人肉去检查。 相应地,无论何时你看到 var
,就假设它会变,并问自己为啥。
尽早地 return
或者 break
当你遇到某些操作需要通过条件判断去执行,应当尽早地退出判断条件:你不应该用下面这种写法
if n.isNumber {// Use n here } else {return }
用这个:
guard n.isNumber else {return } // Use n here
或者你也可以用 if
声明,但是我们推荐你使用 guard
理由: 你一但声明 guard
编译器会强制要求你和 return
, break
或者 continue
一起搭配使用,否则会产生一个编译时的错误。
避免对 可选类型 强解包
如果你有个 FooType?
或 FooType!
的 foo
,尽量不要强行展开它( foo!
)以得到它的关联值。取而代之的,推荐这样:
if let foo = foo {// Use unwrapped `foo` value in here } else {// If appropriate, handle the case where the optional is nil }
或者使用可选链,比如:
// Call the function if `foo` is not nil. If `foo` is nil, ignore we ever tried to make the call foo?.callSomethingIfFooIsNotNil()
理由: if let
绑定可选类型产生了更安全的代码,强行展开很可能导致运行时崩溃。
避免隐式解析的可选类型
如果 foo 可能为 nil
,尽可能的用 let foo: FooType?
代替 let foo: FooType!
(注意:一般情况下, ?
可以代替 !
) 理由: 明确的可选类型产生了更安全的代码。隐式解析的可选类型也可能会挂。
对于只读属性和 subscript
,选用隐式的 getters 方法
如果可以,省略只读属性和 subscript
的 get
关键字 所以应该这样写:
var myGreatProperty: Int {return 4 }subscript(index: Int) -> T {return objects[index] }
……而不是:
var myGreatProperty: Int {get {return 4} }subscript(index: Int) -> T {get {return objects[index]} }
理由: 第一个版本的代码意图已经很清楚了,并且用了更少的代码
对于顶级定义,永远明确的列出权限控制
顶级函数,类型和变量,永远应该有着详尽的权限控制说明符
public var whoopsGlobalState: Int internal struct TheFez {} private func doTheThings(things: [Thing]) {}
然而在这些函数/类型的内部,可以在合适的地方使用隐式权限控制:
internal struct TheFez {var owner: Person = Joshaber() }
理由: 顶级定义指定为 internal
很少有恰当的,要明确的确保经过了仔细的判断。在定义的内部重用同样的权限控制说明符就显得重复,而且默认的通常是合理的。
当指定一个类型时,把 冒号和标识符 连在一起
当指定标示符的类型时,冒号要紧跟着标示符,然后空一格再写类型
class SmallBatchSustainableFairtrade: Coffee { ... }let timeToCoffee: NSTimeInterval = 2func makeCoffee(type: CoffeeType) -> Coffee { ... }
理由: 类型区分号是对于标示符来说的,所以要跟它连在一起。
此外,指定字典类型时,键类型后紧跟着冒号,接着加一个空格,之后才是值类型。
let capitals: [Country: City] = [sweden: stockholm]
需要时才写上 self
当调用 self
的属性或方法时,默认隐式引用 self
:
private class History {var events: [Event]func rewrite() {events = []} }
必要的时候再加上 self
, 比如在(逃逸)闭包里,或者 参数名冲突了:
extension History {init(events: [Event]) {self.events = events}var whenVictorious: () -> () {return {self.rewrite()}} }
原因: 在闭包里用 self
更加凸显它捕获 self
的语义,别处避免了冗长
首选 struct
而非 class
除非你需要 class
才能提供的功能(比如 identity 或 deinit
ializers),不然就用 struct
要注意到继承通常 不 是用 类 的好理由,因为 多态 可以通过 协议 实现,重用 可以通过 组合 实现。比如,这个类的分级
class Vehicle {let numberOfWheels: Intinit(numberOfWheels: Int) {self.numberOfWheels = numberOfWheels}func maximumTotalTirePressure(pressurePerWheel: Float) -> Float {return pressurePerWheel * Float(numberOfWheels)} }class Bicycle: Vehicle {init() {super.init(numberOfWheels: 2)} }class Car: Vehicle {init() {super.init(numberOfWheels: 4)} }
可以重构成酱紫:
protocol Vehicle {var numberOfWheels: Int { get } }func maximumTotalTirePressure(vehicle: Vehicle, pressurePerWheel: Float) -> Float {return pressurePerWheel * Float(vehicle.numberOfWheels) }struct Bicycle: Vehicle {let numberOfWheels = 2 }struct Car: Vehicle {let numberOfWheels = 4 }
理由: 值类型更简单,容易分析,并且 let
关键字的行为符合预期。
默认 class
为 final
class
应该用 final
修饰,并且只有在继承的有效需求已被确定时候才能去使用子类。即便在这种情况(前面提到的使用继承的情况)下,根据同样的规则( class
应该用 final
修饰的规则),类中的定义(属性和方法等)也要尽可能的用 final
来修饰 理由: 组合通常比继承更合适,选择使用继承则很可能意味着在做出决定时需要更多的思考。
能不写类型参数的就别写了
当对接收者来说一样时,参数化类型的方法可以省略接收者的类型参数。比如:
struct Composite<T> {…func compose(other: Composite<T>) -> Composite<T> {return Composite<T>(self, other)} }
可以改成这样:
struct Composite<T> {…func compose(other: Composite) -> Composite {return Composite(self, other)} }
理由: 省略多余的类型参数让意图更清晰,并且通过对比,让返回值为不同的类型参数的情况也清楚了很多。
定义操作符 两边留空格
当定义操作符时,两边留空格。不要酱紫:
func <|(lhs: Int, rhs: Int) -> Int func <|<<A>(lhs: A, rhs: A) -> A
应该写:
func <| (lhs: Int, rhs: Int) -> Int func <|< <A>(lhs: A, rhs: A) -> A
理由: 操作符 由标点字符组成,当立即连着类型或者参数值,会让代码非常难读。加上空格分开他们就清晰了
Swift 编码规范相关推荐
- Swift编码规范(目前swift 4.2,持续更新)
参考项目实际.官方文档.raywenderlich(传送门)等大神总结的swift语言的编码规范,适应目前swift 4.2,笔者会不定期更新,欢迎指正补充 约定,请尽量确保代码编译不残留warnin ...
- JavaScript最全编码规范
转载: JavaScript最全编码规范 类型 ●基本类型:访问基本类型时,应该直接操作类型值 ●string ●number ●boolean ●null ●undefined var foo = ...
- 【C++】Google C++编码规范(三):智能指针
[C++]Google C++编码规范(一):作用域 [C++]Google C++编码规范(二):类 std::unique_ptr std::unique_ptr是C++11标准里新推出的智能指针 ...
- 《阿里巴巴编码规范(JAVA)》学习认证考后感
image.png <阿里巴巴 Java 开发手册>是阿里巴巴集团技术团队的集体智慧结晶和经验总结,经历了多次大规模一线实战的检验及不断完善,系统化地整理成册,回馈给广大开发者. 本手册的 ...
- google python代码规范_如何用好python编码规范,写一手漂亮的代码
前一段时间在编写python 代码的时候编辑器中一直在提示规范问题,因为强迫症的原因,我决定遵循python 的编码规范去编码,然后把需要注意的点记录下来, 帮助自己和大家一起成长. 这是我的main ...
- Python最简编码规范
0.前言 本文是阅读<Python Coding Rule>之后总结的最为精华及简单的编码规范,根据每个人不同喜好有些地方会有不同的选择,我只是做了对自己来说最简单易行的选择,仅供大家参考 ...
- 华为java安全编码规范_Java安全编码之SQL注入
随着互联网的发展,Java语言在金融服务业.电子商务.大数据技术等方面的应用极其广泛.Java安全编码规范早已成为SDL中不可或缺的一部分.本文以Java项目广泛采用的两个框架Hibernate和My ...
- 分享GitHub上一位老外的嵌入式C编码规范(收藏细读)
简 介: 本文分析在头条上分享GitHub上一位老外的嵌入式C编码规范(收藏细读):嵌入式大杂烩. 关键词: 嵌入式,C语句,编程规范 分享GitHub上一位老外的嵌入式C编码规范(收藏细读) §01 ...
- PHP标记风格,编码规范
PHP标记风格 PHP一共支持4种标记风格 <?php echo "这是XML风格的标记"; ?> 脚本风格 <script language="php ...
最新文章
- 3.网络通信协议分类
- 疯子的算法总结(八) 最短路算法+模板
- 乐视android版本点四下,EUI5.9+Android7.0刷机包
- 【牛客 - 368D】动态连通块(并查集+bitset优化)
- 程序员管理思维修炼,只需要反复阅读本篇
- Java实训项目4:GUI学生信息管理系统 - 项目结构图
- 当一个对象实例作为一个参数被传递到方法中时,参数的值就是对该对象的引用。对象的内容可以在被调用的方法中改变,但对象的引用是永远不会改变的.
- python四大器_Python编程四大神兽:迭代器、生成器、闭包和装饰器
- Linux系统配置及服务管理_第03章用户管理
- 《软件需求分析》阅读笔记3
- Source Insight建工程之Kernel
- 四阶龙格库塔matlab计算例题,四阶龙格库塔法matlab实现
- matlabWeibull概率图绘制及讲解
- java+ElementUI前后端分离旅游项目第三天 报团游
- html中自定义快捷键,电脑怎样自定义快捷键简单实现
- 大数据处理需要用到的九种编程语言
- 移动端怎么让底部固定_逆冬:移动端排名应该怎么做?两种匹配移动端实战排名干货分享!...
- vant 动态 粘性布局_Sticky 粘性布局
- 《火车头采集器采集网页数据》火车头配置规则采集信息文章数据。
- ThinkPhp6+Vue智慧医疗后台管理系统