前言
这篇文章是我根据在 SwiftGraphics 工作时的一系列笔记整理出来的。文中大多数建议是经过深思熟虑的，但仍可以有其他类似的解决方法。因此，如果其他方案是有意义的，这些方案会被添加上去。
这个最佳实践不是强加或者推荐 Swift 在程序、面向对象或者函数风格上的应用。更重要的是，这里要讲述的是务实的方法。如有需要的话，某些建议可能会集中在面向对象或者实用的解决方法。
这篇文章讲述的范围主要针对 Swift 语言以及 Swift 标准库。即便如此，如果能提出一个独特的 Swift 的视角和见解，我们依然会提供诸如 Swift 在 Mac OS、iOS、 WatchOS 以及 TV OS 上使用的特别建议。而如何在 Xcode 和 LLDB 上有效地使用 Swift，这样的建议也会以 Hints & tips 的风格提供。
这个过程需要付出很多的努力，非常感谢为本文做出贡献的那些人。
此外，可以在[Swift-Lang slack]里面讨论。
贡献者须知
请先确保所有的示例是可以运行的（某些示例可能不是正确）。这个 markdown 能够转换成一个 Mac OS X playground。
黄金准则
1. 一般来说，Apple 都是正确的，遵循 Apple 喜欢的或者示范的处理方式。在任何情况下，你都应该遵循 Apple 的代码风格，正如他们”The Swift Programming Language” 这本书里面的定义一样。然而 Apple 是个大公司，我们将会看到很多在示例代码中的差异。
2. 永远不要仅仅为了减少代码量而去写代码。尽量依赖Xcode中的自动补全代码,自动建议 , 复制和粘贴。详尽的代码描述风格对其他代码维护者来说是非常有好处的。即便如此，过度的冗余也会失去 Swift 的重要特性：类型推断。
最佳实践
1.命名
正如 Swift Programming Language 中的类型名称都是以大驼峰命名法命名的（例如：VehicleController）。
变量和常量则以小驼峰命名法命名（例如：vehicleName）。
你应该使用 Swift 模板去命名你的代码而不是使用 Objective-C 类前缀的风格（除非和 Objective-C 接连）。
不要使用任何匈牙利标识法（ Hungarian notation ）命名（例如：k为常量，m为方法），应使用简短的命名并且使用 Xcode 的类型 Quick Help (01.png+ click) 去查明变量的类型。同样地，不要使用小写字母+下划线（ SNAKE_CASE ）的命名方式。
唯一比较特别的是 enum 值的命名，这里需要使用大驼峰命名法（这个也是遵循 Apple 的 Swift Programming Language 风格）：
|
1 2 3 |
enum Planet { case Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune } |
在所有可能的情况里，名称的不必要减少和缩写都应该避免，将来你应该能在没有任何损害和依赖 Xcode 的自动补全功能的情况下，确切地指出类型特征” ViewController “。非常普遍的缩写如 URL 是允许的。缩写应该用所有字母大写（ URL ）或者所有字母小写（ url ）表示。对类型和变量使用相同的规则。如果 url 是个类型，则应该为大写，如果是个变量，则应该为小写。
2.注释
注释不应该用来使代码无效，注释代码会使代码无效且影响代码的整洁。如果你想要移除代码，但是仍想保留以防代码在以后会用到，你应该依赖 git 或者 bug tracker 。
3.类型推断
在可能的地方，使用Swift的类型推断以减少多余的类型信息。例如，正确的写法：
|
1 |
var currentLocation = Location() |
而不是：
|
1 |
var currentLocation: Location = Location() |
4.Self 推断
让编译器在所有允许的地方推断 self 。在 init 中设置参数以及 non-escaping closures 中应该显性地使用 self 。例如：
|
1 2 3 4 5 6 7 |
struct Example { let name: String init(name: String) { self.name = name } } |
5.参数列表类型推断
在一个闭包表达式（ closure expression ）中指定参数类型可能导致代码更加冗长。只有当需要指定类型时。
|
1 2 3 4 5 6 7 8 9 10 |
let people = [ ("Mary", 42), ("Susan", 27), ("Charlie", 18), ] let strings = people.map() { (name: String, age: Int) -> String in return "\(name) is \(age) years old" } |
如果编译器能够推断类型，则应该去掉类型定义。
|
1 2 3 4 |
let strings = people.map() { (name, age) in return "\(name) is \(age) years old" } |
使用排序好的参数编号命名（”$0″,”$1″,”$2″）能更好地减少冗余，这经常能够完整匹配参数列表。只有当closure的参数名称中没有过多的信息时，使用编号命名。（例如特别简单的 maps 和 filters ）。
Apple 能够并将会改变由 Objective-C frameworks 转换过来的 Swift 的参数类型。例如，选项被移除或者变为自动展开等。我们应有意地指定你的选项并依赖 Swift 去推断类型，减少在这种情况下程序中断的风险。
你总是应该有节制地指定返回类型。例如，这个参数列表明显过分冗余：
|
1 2 3 4 |
dispatch_async(queue) { () -> Void in print("Fired.") } |
6.常量
在类型定义的时候，常量应该在类型里声明为 static 。例如：
前言
这篇文章是我根据在 SwiftGraphics 工作时的一系列笔记整理出来的。文中大多数建议是经过深思熟虑的，但仍可以有其他类似的解决方法。因此，如果其他方案是有意义的，这些方案会被添加上去。
这个最佳实践不是强加或者推荐 Swift 在程序、面向对象或者函数风格上的应用。更重要的是，这里要讲述的是务实的方法。如有需要的话，某些建议可能会集中在面向对象或者实用的解决方法。
这篇文章讲述的范围主要针对 Swift 语言以及 Swift 标准库。即便如此，如果能提出一个独特的 Swift 的视角和见解，我们依然会提供诸如 Swift 在 Mac OS、iOS、 WatchOS 以及 TV OS 上使用的特别建议。而如何在 Xcode 和 LLDB 上有效地使用 Swift，这样的建议也会以 Hints & tips 的风格提供。
这个过程需要付出很多的努力，非常感谢为本文做出贡献的那些人。
此外，可以在[Swift-Lang slack]里面讨论。
贡献者须知
请先确保所有的示例是可以运行的（某些示例可能不是正确）。这个 markdown 能够转换成一个 Mac OS X playground。
黄金准则
1. 一般来说，Apple 都是正确的，遵循 Apple 喜欢的或者示范的处理方式。在任何情况下，你都应该遵循 Apple 的代码风格，正如他们”The Swift Programming Language” 这本书里面的定义一样。然而 Apple 是个大公司，我们将会看到很多在示例代码中的差异。
2. 永远不要仅仅为了减少代码量而去写代码。尽量依赖Xcode中的自动补全代码,自动建议 , 复制和粘贴。详尽的代码描述风格对其他代码维护者来说是非常有好处的。即便如此，过度的冗余也会失去 Swift 的重要特性：类型推断。
最佳实践
1.命名
正如 Swift Programming Language 中的类型名称都是以大驼峰命名法命名的（例如：VehicleController）。
变量和常量则以小驼峰命名法命名（例如：vehicleName）。
你应该使用 Swift 模板去命名你的代码而不是使用 Objective-C 类前缀的风格（除非和 Objective-C 接连）。
不要使用任何匈牙利标识法（ Hungarian notation ）命名（例如：k为常量，m为方法），应使用简短的命名并且使用 Xcode 的类型 Quick Help (01.png+ click) 去查明变量的类型。同样地，不要使用小写字母+下划线（ SNAKE_CASE ）的命名方式。
唯一比较特别的是 enum 值的命名，这里需要使用大驼峰命名法（这个也是遵循 Apple 的 Swift Programming Language 风格）：
|
1 2 3 |
enum Planet { case Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune } |
在所有可能的情况里，名称的不必要减少和缩写都应该避免，将来你应该能在没有任何损害和依赖 Xcode 的自动补全功能的情况下，确切地指出类型特征” ViewController “。非常普遍的缩写如 URL 是允许的。缩写应该用所有字母大写（ URL ）或者所有字母小写（ url ）表示。对类型和变量使用相同的规则。如果 url 是个类型，则应该为大写，如果是个变量，则应该为小写。
2.注释
注释不应该用来使代码无效，注释代码会使代码无效且影响代码的整洁。如果你想要移除代码，但是仍想保留以防代码在以后会用到，你应该依赖 git 或者 bug tracker 。
3.类型推断
在可能的地方，使用Swift的类型推断以减少多余的类型信息。例如，正确的写法：
|
1 |
var currentLocation = Location() |
而不是：
|
1 |
var currentLocation: Location = Location() |
4.Self 推断
让编译器在所有允许的地方推断 self 。在 init 中设置参数以及 non-escaping closures 中应该显性地使用 self 。例如：
|
1 2 3 4 5 6 7 |
struct Example { let name: String init(name: String) { self.name = name } } |
5.参数列表类型推断
在一个闭包表达式（ closure expression ）中指定参数类型可能导致代码更加冗长。只有当需要指定类型时。
|
1 2 3 4 5 6 7 8 9 10 |
let people = [ ("Mary", 42), ("Susan", 27), ("Charlie", 18), ] let strings = people.map() { (name: String, age: Int) -> String in return "\(name) is \(age) years old" } |
如果编译器能够推断类型，则应该去掉类型定义。
|
1 2 3 4 |
let strings = people.map() { (name, age) in return "\(name) is \(age) years old" } |
使用排序好的参数编号命名（”$0″,”$1″,”$2″）能更好地减少冗余，这经常能够完整匹配参数列表。只有当closure的参数名称中没有过多的信息时，使用编号命名。（例如特别简单的 maps 和 filters ）。
Apple 能够并将会改变由 Objective-C frameworks 转换过来的 Swift 的参数类型。例如，选项被移除或者变为自动展开等。我们应有意地指定你的选项并依赖 Swift 去推断类型，减少在这种情况下程序中断的风险。
你总是应该有节制地指定返回类型。例如，这个参数列表明显过分冗余：
|
1 2 3 4 |
dispatch_async(queue) { () -> Void in print("Fired.") } |
