當我們編寫這本書，或者在我們自己的項目中使用 Swift 代碼時，我們盡量遵循如下的原則：
對于命名，在使用時能清晰表意是最重要。因為 API 被使用的次數要遠遠多于被聲明的次數，所以我們應當從使用者的角度來考慮它們的名字。盡快熟悉 Swift API 設計準則，并且在你自己的代碼中堅持使用這些準則。
簡潔經常有助于代碼清晰，但是簡潔本身不應該獨自成為我們編碼的目標。
務必為函數添加文檔注釋 — 特別是泛型函數。
類型使用大寫字母開頭，函數、變量和枚舉成員使用小寫字母開頭，兩者都使用駝峰式命名法。
使用類型推斷。省略掉顯而易見的類型會有助于提高可讀性。
如果存在歧義或者在進行定義的時候不要使用類型推斷。(比如 func 就需要顯式地指定返回類型)
優先選擇結構體，只在確實需要使用到類特有的特性或者是引用語義時才使用類。
除非你的設計就是希望某個類被繼承使用，否則都應該將它們標記為 final。
除非一個閉包后面立即跟隨有左括號，否則都應該使用尾隨閉包 (trailing closure) 的語法。
使用 guard 來提早退出方法。
避免對可選值進行強制解包和隱式強制解包。它們偶爾有用，但是經常需要使用它們的話往往意味著有其他不妥的地方。
不要寫重復的代碼。如果你發現你寫了好幾次類似的代碼片段的話，試著將它們提取到一個函數里，并且考慮將這個函數轉化為協議擴展的可能性。
試著去使用 map 和 reduce，但這不是強制的。當合適的時候，使用 for 循環也無可厚非。高階函數的意義是讓代碼可讀性更高。但是如果使用 reduce 的場景難以理解的話，強行使用往往事與愿違，這種時候簡單的 for 循環可能會更清晰。
試著去使用不可變值：除非你需要改變某個值，否則都應該使用 let 來聲明變量。不過如果能讓代碼更加清晰高效的話，也可以選擇使用可變的版本。用函數將可變的部分封裝起來，可以把它帶來的副作用進行隔離。
Swift 的泛型可能會導致非常長的函數簽名。壞消息是我們現在除了將函數聲明強制寫成幾行以外，對此并沒有什么好辦法。我們會在示例代碼中在這點上保持一貫性，這樣你能看到我們是如何處理這個問題的。
除非你確實需要，否則不要使用 self.。在閉包表達式中，使用 self 是一個清晰的信號，表明閉包將會捕獲 self。
盡可能地對現有的類型和協議進行擴展，而不是寫一些全局函數。這有助于提高可讀性，讓別人更容易發現你的代碼。
