編碼風格是一個比較古老的話題，一般認爲它最早是在布里安·柯尼漢(Brian Kernighan)和丹尼斯·裏奇(Dennis Ritchie)合作出版的《The C Programming Language》一書中出現的，這一風格也被稱之爲K&R風格。現在大多數程序員使用的編碼風格是Google編碼風格。雖然對於機器而言，編碼風格並沒有什麼卵用，但是對於程序員而言，良好的編碼風格還是非常的重要。因此，我們應該在日常編碼過程中自覺養成良好的編碼習慣。
儘管Xcode非常強大，有很多編碼格式已經不需要我們手動去調整，但是還是有一些編碼風格是編程工具無法幫我們去完成的，所以我們還是有必要學習一些他人總結的好的編碼規範。
1、命名最好做到見名知意
在代碼中命名過程中，最好是能清楚的表述代碼的意思。一個毫無意義的命名會增加代碼閱讀者的困惑，非常不利於自己後續維護，也不利於和其他人進行交流。關於代碼命名規範，可以參考蘋果官方的Swift API設計準則。
2、類型最好是用駝峯標識
與這一點有關的內容參見《Swift命名規範》
3、儘可能的使用let
在聲明一個變量時，儘量使用let，以防止變量被意外修改，從而保證程序的安全性。一個引用類型的變量也可以使用let來聲明。使用let聲明的引用類型，只是引用本身被常量化了，並不是指它引用的對象被常量化。也就是說，你不能再給這個引用賦一個新的值，但是，該引用所指向的對象卻是可以改變的。比如說：
// 引用本身是常量
let view = UIView()
// 但是可以改變引用對象的內容
view.backgroundColor = .red // 這裏代碼不會出錯
// 不過不能再給這個引用賦一個新的值
view = UIView() // 這裏代碼會出錯4、儘量使用類型推斷
Swift的編譯器非常強大，它可以根據字面量來推斷具體的類型。所以，爲了提高代碼的閱讀性，儘量不要使用顯而易見的類型聲明。除非不加類型聲明容易產生歧義，比如說：
// 這是一個Array類型的數組
let arr = ["LeBron James", "Carmelon Anthony", "Dwyane Wade", "Chris Paul"]
// 這是一個Set類型的集合
let set: Set = ["LeBron James", "Carmelon Anthony", "Dwyane Wade", "Chris Paul"]像上面聲明一個Set類型的集合時，如果省略類型Set，編譯器就會直接將其推斷爲Array類型。還有，集合類型一般是指Array、Set和Dictionary的總稱，但是有時候我們也會把Set類型的變量或者常量也稱之爲集合。在碰到別人說“集合”時，應該根據上下文意思來理解他到底是在說Set，還是在說Array、Set和Dictionary這一類的總稱。其實這個也沒什麼好說的。
5、優先使用結構體
在Swift中，結構體的功能非常強大，它也具有面向對象的特性。一般而言，如果不是需要使用類才具有的特性時，儘量使用結構體。關於什麼時候使用結構體，什麼時候使用類，詳情參見《Swift中常用的數據結構(上)》中第一部分的內容，或者直接查看蘋果官方文檔Classes and Structures的內容。
6、使用final標記
在設計類時，如果不是用來作爲其他類的父類(或者說這個類不需要子類)，應該將它標記爲final。
7、學會使用guard
guard語句幾乎可以完成if語句的所有功能，但是有時候使用guard比使用if語句閱讀性要好，尤其是在替代if-else嵌套語句時，guard語句的優勢十分明顯。另外，在方法中最好是使用guard提早退出方法。
8、儘量使用尾隨閉包
如果不是使用閉包作爲返回值，儘量使用尾隨閉包。
9、儘可能的少用強制解包
不管是強制解包還是隱式強制解包，它都是一個非常危險的操作，使用不當很容易造成程序崩潰。比較好的習慣是使用if或者guard進行安全校驗。
10、熟練的抽取重複的代碼
不管是出於代碼簡介層面的考慮，還是出於代碼複用的角度考慮，你都應該將相似的代碼片段抽取到一個函數裏，甚至還可以考慮將這個函數轉化爲協議擴展。
11、儘量少些self.
如果代碼不會出現歧義，或者是因爲其它需要，儘量不要寫self.。
12、儘量少寫全局函數
出於代碼閱讀性方面的考慮，儘可能多的對現有的類型和協議進行相應的擴展，而不是一味的去寫全局函數。
關於Swift編碼風格的話題暫時先寫到這裏，以後如果學到更多有關的知識，再回過頭來進行相應的補充。