iOS代碼規範

每一個公司有每一個公司的代碼規範，學習記錄下新公司iOS代碼規範：

 

命名

命名規則對於維護代碼來講是很是重要的，清晰簡潔的命名有利於團隊合做 。總的講不要使用單詞的簡寫，除了很是經常使用的簡寫之外，儘可能使用單詞全稱。API的名稱不要有歧義。如下是命名的細則：

1.1.命名不要使用通用的模糊的命名，準確命名，不要縮寫簡寫命名或用單個字母命名。

1.2.命名優雅：參考Almofire中 public func stream(withHostName hostName: String, port: Int) -> StreamRequest   。

1.3.類型命名都是以大駝峯命名，變量和常量使用小駝峯命名。不要使用任何匈牙利標識法（ Hungarian notation ）命名（例如：k爲常量，m爲方法），應使用簡短的命名而且使用 Xcode 的類型 Quick Help (01.png+ click) 去查明變量的類型。一樣地，不要使用小寫字母+下劃線（ SNAKE_CASE ）的命名方式。

1.4.命名中避免重複的詞語，可參照swift官方文檔規定，以下：

                   // Swift 3 definition

                      prepare(for segue: UIStoryboardSegue, sender: Any?)

                      // Swift 3 calling code

                      viewController.prepare(for: segue, sender: something)

1.5.func命名中含有默認值的參數放在最後。

1.6.定義每一個func傳入、返回參數標籤的格式，儘可能按照swift規範格式來寫，如此代碼結構更加清晰，方便本身和別人維護閱覽。

              {例如：

              (message : T, file : String = #file, lineNumber : Int = #line, FuncName: String = #function)

              而非

             (message:T,file:String=#file,lineNumber:Int=#line,FuncName:String=#function)

            注意空格、逗號、冒號，以及換行，特別是空格！

           }

1.7.圖片名稱應該被統一命名以保持組織的完整。它們應該被命名爲一個說明它們用途的駝峯式字符串，其次是自定義類或屬性的無前綴名字（若是有的話），而後進一步說明顏色 和/或 展現位置，最後是它們的狀態。例如：

RefreshBarButtonItem / RefreshBarButtonItem@2x 和 RefreshBarButtonItemSelected / RefreshBarButtonItemSelected@2x

ArticleNavigationBarWhite / ArticleNavigationBarWhite@2x 和 ArticleNavigationBarBlackSelected / ArticleNavigationBarBlackSelected@2x.

 

方法

2.1. 構造方法 可直接使用類名+.形式調用例：NoticeinfoModel(responseData: JSON)  不須要寫init (  NoticeinfoModel.init(responseData: JSON)  ) 。

2.2. 當在解析時網絡框架將轉成 SwiftyJSON   因此 解析時 儘可能用 stringValue 防止數據爲空 。

類代碼組織原則

一個原則：析構函數deinit 最好放到類最上面，第一眼就能夠看到這個方法，能夠方便看到是否remove了一些操做，對內存的合理釋放等，controller，view的生命週期函數放到最上面，本身實現的方法在下面，相同/相近功能的方法採用#pragma mark -來標記，以便查看。

註釋

當須要的時候，註釋應該被用來解釋 爲何 特定代碼作了某些事情。所使用的任何註釋必須保持最新不然就刪除掉。

一般應該避免一大塊註釋，代碼就應該儘可能做爲自身的文檔，只須要隔幾行寫幾句說明。這並不適用於那些用來生成文檔的註釋。

3.1.有些閉包沒法體現其功能的需加註釋。

3.2.model中的變量須要添加註釋。

3.3.服務器返回的枚舉類型需加註釋，不要使用magic number來標識一個變量的值。

文件結構

iOS工程文件結構分物理結構和邏輯結構，建議邏輯結構和物理結構保持一致，以便方便有效地管理類文件。在實際中使用中，項目實際負責人能夠結合項目特色靈活使用，但基本的原則必定要保持，保持良好的類文件組織結構。

4.1. 建議一個文件不要超過1500行。

4.2. 建議一個函數或者方法不要超過一屏。

4.3. 無用的代碼，包括Xcode生成的模板代碼和佔位符註釋應該刪除，除非是有目的性的保留這些代碼。一些方法內只是簡單地調用了父類裏面的方法也須要刪除。

4.4. contorller裏view建議抽出來，view裏不要耦合model。

4.5. view中的控件建議使用私有來修飾，使用方法去修改view中的控件的值。

4.6. 使用MARK進行代碼的分段，結構清晰。

 

Swift使用規範

5.1. 爲了保持簡潔，能夠避免使用 self 關鍵詞。

5.2. 空格的使用參照標準的apple sample code，統一使用。

5.3. 合理的使用private 和  fileprivate, 推薦使用private，在使用extension時可以使用fileprivate。

5.4. 當不肯定數據是否爲空時可用 ?? 方式 例如 print(str ?? 「")。

5.5. 優先使用Swift原生類型，能夠根據須要使用Objective-C提供的方法。

5.6. 僅在閉包表達式參數在參數列表中最後一個時，使用尾隨閉包表達式。閉包參數命名要有描述性。

5.7. 使用數組時 可指定元素類型 例：var noticeArr = [JSON]() 如不須要實例化則  var noticeArr : [JSON]? 。

5.8. 單例使用shared(不要使用shareInstance，shareClient之類的其餘名字)。

Xcode工程

6.1. 使用showInFinder形式去真正建立文件，拖進project中。

6.2. xcassets中根據項目模塊結構方式添加對應的文件，不要單獨把圖片拖進xcassets中，刪掉圖片須要在xcassets中delete刪掉，保證圖片對應的json也刪掉。

6.3. 爲了不文件雜亂，物理文件應該保持和 Xcode 項目文件同步。Xcode 建立的任何組（group）都必須在文件系統有相應的映射。

6.4. 爲了更清晰，代碼不只應該按照類型進行分組，也能夠根據功能進行分組。若是能夠的話，儘量一直打開 target Build Settings 中 「Treat Warnings as Errors」 以及一些額外的警告。若是你須要忽略指定的警告,使用 Clang 的編譯特性 。