iOS开发入门——17条 Swift 最佳实践规范(上)

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS开发入门——17条 Swift 最佳实践规范(上)相关的知识,希望对你有一定的参考价值。

  文章来源:http://www.zretc.com/technologyDetail/432.html

  前言

  这篇ios开发入门文章是我根据在 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 风格):

  enum Planet { case Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune}

  在所有可能的情况里,名称的不必要减少和缩写都应该避免,将来你应该能在没有任何损害和依赖 Xcode 的自动补全功能的情况下,确切地指出类型特征" ViewController "。非常普遍的缩写如 URL 是允许的。缩写应该用所有字母大写( URL )或者所有字母小写( url )表示。对类型和变量使用相同的规则。如果 url 是个类型,则应该为大写,如果是个变量,则应该为小写。

  2.注释

  注释不应该用来使代码无效,注释代码会使代码无效且影响代码的整洁。如果你想要移除代码,但是仍想保留以防代码在以后会用到,你应该依赖 git 或者 bug tracker 。

  3.类型推断

  在可能的地方,使用Swift的类型推断以减少多余的类型信息。例如,正确的写法:

  var currentLocation = Location()

  而不是:

  var currentLocation: Location = Location()

  4.Self 推断

  让编译器在所有允许的地方推断 self 。在 init 中设置参数以及 non-escaping closures 中应该显性地使用 self 。例如:

  struct Example { let name: String init(name: String) { self.name = name }}

  5.参数列表类型推断

  在一个闭包表达式( closure expression )中指定参数类型可能导致代码更加冗长。只有当需要指定类型时。

  let people = [ ("Mary", 42), ("Susan", 27), ("Charlie", 18),] let strings = people.map() { (name: String, age: Int) -> String in return "(name) is (age) years old"}

  如果编译器能够推断类型,则应该去掉类型定义。

  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 去推断类型,减少在这种情况下程序中断的风险。

  你总是应该有节制地指定返回类型。例如,这个参数列表明显过分冗余:

  dispatch_async(queue) { () -> Void in print("Fired.")}

  6.常量

  在类型定义的时候,常量应该在类型里声明为 static 。例如:

  struct PhysicsModel { static var speedOfLightInAVacuum = 299_792_458}class Spaceship {

  static let topSpeed = PhysicsModel.speedOfLightInAVacuum var speed: Double func fullSpeedAhead() { speed = Spaceship.topSpeed }}

  使用 static 修饰常量可以允许他们在被引用的时候不需要实例化类型。

  除了单例以外,应尽量避免生成全局常量。

  7.计算型类型属性(Computed Properties)

  当你只需要继承 getter 方法时,返回简单的 Computed 属性即可。例如,应该这样做:

  class Example { var age: UInt32 { return arc4random() }}

  而不是:

  class Example { var age: UInt32 { get { return arc4random() } }}

  如果你在属性中添加了 set 或者 didSet ,那么你应该显示地提供 get 方法。

  class Person { var age: Int { get { return Int(arc4random()) } set { print("That‘s not your age.") } }}

  8.实例转换(Converting Instances)

  当创建代码去从一个类型转换到另外的 init() 方法:

  extension NSColor { convenience init(_ mood: Mood) { super.init(color: NSColor.blueColor) }}

  在 Swift 标准库中,对于把一个类型的实例转换为另外一种,现在看来 init 方法是比较喜欢用的一种方式。

  "to" 方法是另外一种比较合理的技术(尽管你应该遵循 Apple 的引导去使用 init 方法):

  struct Mood { func toColor() -> NSColor { return NSColor.blueColor() }}

  而你可能试图去使用一个getter,例如:

  struct Mood { var color: NSColor { return NSColor.blueColor() }}

  getters 通常由于应该返回可接受类型的组件而受到限制。例如,返回了 Circle 的实例是非常适合使用 getter 的,但是转换一个 Circle 为 CGPath 最好在 CGPath 上使用"to"函数或者 init() 扩展。

  下篇:iOS开发——17条 Swift 最佳实践规范(下)

  更多IOS开发入门知识请访问中软国际教育集团技术知识库

以上是关于iOS开发入门——17条 Swift 最佳实践规范(上)的主要内容,如果未能解决你的问题,请参考以下文章

Swift iOS 应用程序到 REST PHP API - 身份验证的最佳实践是啥?

团队开发中 Git 最佳实践,不给队友拖后腿

SpringCloud 微服务最佳开发实践

Redis最佳实践:7个维度+43条使用规范,带你彻底玩转Redis | 附实践清单

iOS - 在 Swift 中获取集合的异步属性的最佳实践

iOS:在 Swift 中重新创建 addTarget() 的最佳实践?