文档编号：
应用开发Swift编码规范
（版本v1.0.0）
成文信息 |
||||||
|
主题词： |
Swift开发编码规范 |
|||||
|
作 者： |
周少停 |
文档类别： |
开发规范 |
|||
|
审 核： |
||||||
|
批 准： |
文档性质： |
初稿 |
||||
|
主 送： |
存档日期： |
|||||
|
抄 送： |
发布日期： |
2016年4月8号 |
||||
|
变更信息 |
||||||
|
版本 |
原因 |
作者 |
日期 |
|||
第一章 概述
1.1 编写目的
开发规范制定的目的是为了保证在系统设计、编码、测试、维护的过程中项目组人员遵循一套统一系统设计标准、应用程序编写标准、页面风格标准，
借以提高软件开发团队的效率、增加代码的统一性、可读性，可维护性，保障项目开发稳定。
本文档的阅读对象为开发人员。
本文档提供了项目开发的各项规范以及指导原则。开发人员在开发过程中必须严格遵守此开发规范。
1.2 定义
基类：应用程序最底层的程序支撑，封装应用程序的基本功能和框架实现。
本文中凡是规范标题下的内容，都是开发过程中必须遵守的约定。
本文中凡是注意事项标题下的内容，都是开发过程中最好遵守的原则，它们多是一些技巧的提示，可提高应用程序的性能，避免不必要的错误。
1.3 参考资料
想要了解更多Swift,请查阅以下链接:
github官方网站:https://github.com/
苹果Swift官方网站:https://developer.apple.com/swift/
Swift学习网站(SwiftV视频课堂):http://www.swiftv.cn/
Swift学习网站(极客学院):http://search.jikexueyuan.com/course/?q=swift
Swift指南:https://github.com/ipader/SwiftGuide
Swift代码规范:https://github.com/Artwalk/swift-style-guide/blob/master/README_CN.md
https://github.com/raywenderlich/swift-style-guide
第二章 代码格式与风格
2.1 基本原则
代码格式与风格的基本原则是：便于开发，易于交流，前后一致，符合本规范求，形成全公司统一风格。
- 缩进精确，减少程序员犯错的可能
- 明确意图
- 减少冗余
- 少量关于美的讨论
2.2 新建工程
- Product Name使用英文,第一个首字母大写
- Organization Name:9elephas
- Organization Identifer:com.9elephas
2.3 缩进
子功能块当在其父功能块后缩进。
当功能块过多而导致缩进过深时当将子功能块提取出来做为子函数。
- 用 Tabs，而非 空格
- 文件结束时留一空行
- 用足够的空行把代码分割成合理的块
- 不要在一行结尾留下空白
- 千万别在空行留下缩进
使用缩进2个空格，而不是制表符，以节省空间，并有助于防止换行。请务必在Xcode中设置此偏好。
如:
2.4 长度
为便于阅读和理解，单个函数的有效代码长度当尽量控制在100行以内（不包括注释行），当一个功能模块过大时往往造成阅读困难，
因此当使用子函数等将相应功能抽取出来，这也有利于提高代码的重用度。
单个类也不宜过大，当出现此类情况时当将相应功能的代码重构到其他类中，通过组合等方式来调用，建议单个类的长度包括注释行不超过1500行。
尽量避免使用大类和长方法。
2.5 行宽
页宽应该设置为80字符。一般不要超过这个宽度, 这会导致在某些机器中无法以一屏来完整显示, 但这一设置也可以灵活调整。
在任何情况下, 超长的语句应该在一个逗号后或一个操作符前折行。一条语句折行后, 应该比原来的语句再缩进一个TAB或4个空格，以便于阅读。
一行代码长度也最好控制在80字符以内,该功能可在Xcode里面设置.
2.6 间隔
类、方法及功能块间等应以空行相隔，以增加可读性，但不得有无规则的大片空行。
操作符两端应当各空一个字符以增加可读性。
相应独立的功能模块之间可使用注释行间隔，并标明相应内容.
2.7 括号
Swift中括号不同其他编程语言,这里需要注意.如:
同时,{ }的使用规划应该为:
而不是
2.8 分号
Swift不需要分号来换行,所以在每行代码结束时,最好不要加分号,除非一行之上有两句代码,这时才需要在每句代码结束之后加分号
但是,不推荐一行之上写多句代码.
第三章 注释
3.1 基本原则
- 注释应该增加代码的清晰度。代码注释的目的是要使代码更易于被其他开发人员等理解。
- 如果你的程序不值得注释，那么它很可能也不值得运行。
- 避免使用装饰性内容。
- 保持注释的简洁。
- 注释信息不仅要包括代码的功能，还应给出原因。
- 不要为注释而注释。
- 除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
3.2 单行注释
单行注释使用//即可
3.2 多行注释
多行注释使用/**/
如:
3.3 类注释
在每个类开始的时候,Xcode会自动写上有关该类.该工程的信息,这时需要为该类写上注释:该类的功能.注意事项等.如
3.3 方法注释
为每一个方法写上注释,该方法的功能.注意事项等,使用MARK标记.
第四章 字段
4.1 类名.自定义协议名.枚举
类名.自定义协议名.枚举采用大驼峰命名法,类名每个单词的首字母都应该大写.如:
4.2 方法名.
方法名.协议名采用小驼峰命名法.第一个单词的首字母小写,其余单词的首字母大写.
4.3 变量名.常量名.集合名.
变量名.常量名.集合名一律采用小驼峰命名法,如果只有一个单词,则一律小写.
4.4 类型推断
尽可能地使用Swift原生类型.如:
应尽量避免:
4.5计算属性
为了保持简洁，如果一个计算属性是只读的，请忽略掉get语句。只有在需要定义set语句的时候，才提供get语句。
推荐:
不推荐:
4.6函数声明
保证短的函数定义在同一行中，并且包含左大括号：
在一个长的函数定义时，在适当的地方进行换行，同时在下一行中添加一个额外的缩进：
4.7闭包表达式
如果闭包表达式参数在参数列表中的最后一个时，使用尾部闭包表达式。给定闭包参数一个描述性的命名。
推荐做法：
不推荐做法：
当单个闭包表达式上下文清晰时，使用隐式的返回值：
4.8结构体构造器
使用原生的 Swift 结构体构造器，比老式的几何类（CGGeometry）的构造器要好。
推荐:
不推荐:
4.9语法糖
推荐使用类型定义简洁的版本，而不是全称通用语法。
推荐:
不推荐:
4.10控制流
推荐循环使用for-in表达式，而不使用for-condition-increment表达式。
推荐:
不推荐:
第五章 其他
5.1.能用 let 尽量用 let 而不是 var
一个好的技巧是，使用 let 定义任何东西，只有在编译器告诉我们值需要改变的时候才改成 var 定义。
5.2.尽早地 Return 或者 break
当你遇到某些操作需要通过条件判断去执行，应当尽早地退出判断条件,如
而不应该
5.3.避免对 可选类型 强解包
5.4.当指定一个类型时，把 冒号和标识符 连在一起
当指定标示符的类型时，冒号要紧跟着标示符，然后空一格再写类型
5.5.需要时才写上 self
需要时才写上 self,当调用 self 的 properties 或 methods 时，self 用默认的隐式引用：
self 的 properties 或 methods 时，self 用默认的隐式引用：
必要的时候再加上self, 比如在闭包里，或者 参数名冲突了：
5.6.首选 structs 而非 classes
除非你需要 class 才能提供的功能（比如 identity 或 deinitializers），不然就用 struct
要注意到继承通常不是用 类 的好理由，因为 多态 可以通过 协议 实现，重用 可以通过 组合 实现。
比如，这个类的分级
可以重构成这个这样:
5.7.操作定义符 两边留空格
当定义操作定义符 时，两边留空格
推荐
a = b ++
不推荐
a=b++