Swift 编码规范

留空白

  • 用 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 = 2 func 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 或 deinitializers),不然就用 struct要注意到继承通常 不 是用 类 的好理由,因为 多态 可以通过 协议 实现,重用 可以通过 组合 实现。比如,这个类的分级

class Vehicle { let numberOfWheels: Int init(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

理由: 操作符 由标点字符组成,当立即连着类型或者参数值,会让代码非常难读。加上空格分开他们就清晰了 .

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,830评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,992评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,875评论 0 331
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,837评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,734评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,091评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,550评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,217评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,368评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,298评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,350评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,027评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,623评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,706评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,940评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,349评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,936评论 2 341