標籤:
文檔編號:
應用開發Swift編碼規範
(版本v1.0.0)
成文資訊 |
主題詞: |
Swift開發編碼規範 |
作 者: |
周少停 |
文檔類別: |
開發規範 |
審 核: |
|
批 准: |
|
文檔性質: |
初稿 |
主 送: |
|
存檔日期: |
|
抄 送: |
|
發布日期: |
2016年4月8號 |
變更資訊 |
版本 |
原因 |
作者 |
日期 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第一章 概述1.1 編寫目的
開發規範制定的目的是為了保證在系統設計、編碼、測試、維護的過程中項目組人員遵循一套統一系統設計標準、應用程式編寫標準、頁面風格標準,
藉以提高軟體Team Dev的效率、增加代碼的統一性、可讀性,可維護性,保障項目開發穩定。
本文檔的閱讀對象為開發人員。
本文檔提供了項目開發的各項規範以及指導原則。開發人員在開發過程中必須嚴格遵守此開發規範。
1.2 定義
基類:應用程式最底層的程式支撐,封裝應用程式的準系統和架構實現。
本文中凡是規範標題下的內容,都是開發過程中必須遵守的約定。
本文中凡是注意事項標題下的內容,都是開發過程中最好遵守的原則,它們多是一些技巧的提示,可提高應用程式的效能,避免不必要的錯誤。
1.3 參考資料
想要瞭解更多Swift,請查閱以下連結:
github官方網站:https://github.com/
蘋果Swift官方網站:https://developer.apple.com/swift/
Swift學習網站(SwiftV視頻課堂):http://www.swiftv.cn/
Swift學習網站(極客學院):http://search.jikexueyuan.com/course/?q=swift
Swift指南:https://github.com/ipader/SwiftGuide
Swift代碼規範:https://github.com/Artwalk/swift-style-guide/blob/master/README_CN.md
https://github.com/raywenderlich/swift-style-guide
第二章 代碼格式與風格 2.1 基本原則
代碼格式與風格的基本原則是:便於開發,易於交流,前後一致,符合本規範求,形成全公司統一風格。
- 縮排精確,減少程式員犯錯的可能
- 明確意圖
- 減少冗餘
- 少量關於美的討論
2.2 建立工程
- Product Name使用英文,第一個首字母大寫
- Organization Name:9elephas
- Organization Identifer:com.9elephas
2.3 縮排
子功能塊當在其父功能塊後縮排。
當功能塊過多而導致縮排過深時當將子功能塊提取出來做為子函數。
- 用 Tabs,而非 空格
- 檔案結束時留一空行
- 用足夠的空行把代碼分割成合理的塊
- 不要在一行結尾留下空白
- 千萬別在空行留下縮排
使用縮排2個空格,而不是定位字元,以節省空間的,並有助於防止換行。請務必在Xcode中設定此偏好。
如:
2.4 長度
為便於閱讀和理解,單個函數的有效代碼長度當盡量控制在100行以內(不包括注釋行),當一個功能模組過大時往往造成閱讀困難,
因此當使用子函數等將相應功能抽取出來,這也有利於提高代碼的重用度。
單個類也不宜過大,當出現此類情況時當將相應功能的代碼重構到其他類中,通過組合等方式來調用,建議單個類的長度包括注釋行不超過1500行。
盡量避免使用大類和長方法。
2.5 行寬
頁寬應該設定為80字元。一般不要超過這個寬度, 這會導致在某些機器中無法以一屏來完整顯示, 但這一設定也可以靈活調整。
在任何情況下, 超長的語句應該在一個逗號後或一個操作符前折行。一條語句折行後, 應該比原來的語句再縮排一個TAB或4個空格,以便於閱讀。
一行代碼長度也最好控制在80字元以內,該功能可在Xcode裡面設定.
2.6 間隔
類、方法及功能塊間等應以空行相隔,以增加可讀性,但不得有無規則的大片空行。
操作符兩端應當各空一個字元以增加可讀性。
相應獨立的功能模組之間可使用注釋行間隔,並標明相應內容.
2.7 括弧
Swift中括弧不同其他程式設計語言,這裡需要注意.如:
同時,{ }的使用規劃應該為:
而不是
2.8 分號
Swift不需要分號來換行,所以在每行代碼結束時,最好不要加分號,除非一行之上有兩句代碼,這時才需要在每句代碼結束之後加分號
但是,不推薦一行之上寫多句代碼.
第三章 注釋3.1 基本原則
- 注釋應該增加代碼的清晰度。代碼注釋的目的是要使代碼更易於被其他開發人員等理解。
- 如果你的程式不值得注釋,那麼它很可能也不值得運行。
- 避免使用裝飾性內容。
- 保持注釋的簡潔。
- 注釋資訊不僅要包括代碼的功能,還應給出原因。
- 不要為注釋而注釋。
- 除變數定義等較短語句的注釋可用行章節附註釋外,其他注釋當避免使用行章節附註釋。
3.2 單行注釋
單行注釋使用//即可
3.2 多行注釋
多行注釋使用/**/
如:
3.3 類注釋
在每個類開始的時候,Xcode會自動寫上有關該類.該工程的資訊,這時需要為該類寫上注釋:該類的功能.注意事項等.如
3.3 方法注釋
為每一個方法寫上注釋,該方法的功能.注意事項等,使用MARK標記.
第四章 欄位4.1 類名.自訂協議名.枚舉
類名.自訂協議名.枚舉採用大駝峰命名法,類名每個單詞的首字母都應該大寫.如:
4.2 方法名.
方法名.協議名採用小駝峰命名法.第一個單詞的首字母小寫,其餘單詞的首字母大寫.
4.3 變數名.常量名.集合名.
變數名.常量名.集合名一律採用小駝峰命名法,如果只有一個單詞,則一律小寫.
4.4 類型推斷
儘可能地使用Swift原生類型.如:
應盡量避免:
4.5
計算屬性
為了保持簡潔,如果一個計算屬性是唯讀,請忽略掉get語句。只有在需要定義set語句的時候,才提供get語句。
推薦:
不推薦:
4.6函式宣告
保證短的函數定義在同一行中,並且包含左大括弧:
在一個長的函數定義時,在適當的地方進行換行,同時在下一行中添加一個額外的縮排:
4.7閉包運算式
如果閉包運算式參數在參數列表中的最後一個時,使用尾部閉包運算式。給定閉包參數一個描述性的命名。
推薦做法:
不推薦做法:
當單個閉包運算式上下文清晰時,使用隱式的傳回值:
4.8結構體構造器
使用原生的 Swift 結構體構造器,比老式的幾何類(CGGeometry)的構造器要好。
推薦:
不推薦:
4.9文法糖
推薦使用類型定義簡潔的版本,而不是全稱通用文法。
推薦:
不推薦:
4.10控制流程
推薦迴圈使用for-in運算式,而不使用for-condition-increment運算式。
推薦:
不推薦:
第五章 其他5.1.能用
let
盡量用
let
而不是
var
一個好的技巧是,使用 let 定義任何東西,只有在編譯器告訴我們值需要改變的時候才改成 var 定義。
5.2.儘早地
Return
或者
break
當你遇到某些操作需要通過條件判斷去執行,應當儘早地退出判斷條件,如
而不應該
5.3.避免對 可選類型 強解包5.4.當指定一個類型時,把 冒號和標識符 連在一起
當指定標示符的類型時,冒號要緊跟著標示符,然後空一格再寫類型
5.5.需要時才寫上
self
需要時才寫上
self,當調用 self
的 properties
或 methods
時,self
用預設的隱式引用:
必要的時候再加上self
, 比如在閉包裡,或者 參數名衝突了:
5.6.首選
structs
而非
classes
除非你需要 class
才能提供的功能(比如 identity
或 deinitializers
),不然就用 struct
要注意到繼承通常不是用 類 的好理由,因為 多態 可以通過 協議 實現,重用 可以通過 組合 實現。
比如,這個類的分級
可以重構成這個這樣:
5.7.操作定義符 兩邊留空格
當定義操作定義符 時,兩邊留空格
推薦
a = b ++
不推薦
a=b++
Swift編程規範