iOS App開發的那些事兒1：如何建立合適的規範

標籤：ati   source   ios   種類型   cell   section   服務管理   gen   登入   

《iOS App開發的那些事兒》系列文章從更宏觀的角度出發，不僅僅局限於具體某個功能、介面的實現，而是結合網易雲信iOS端研發負責人多年的經驗，從如何最佳化現有代碼的角度出發，深度分析如何創造出iOS App開發中比較合適的規範和架構。

 

推薦閱讀

iOS App開發的那些事兒2：如何搭建合適的架構

 

將代碼規範合理分級

大家都理解軟體開發需要合適的規範：代碼規範，程式規範，流程規範等等，以此來減少意外的出現：最少驚訝原則。但在實際執行中卻會碰到各種情況，其中最大的問題是：怎麼鑒別哪些規範是需要強制執行，哪些規範是推薦執行。

規範的強制執行帶來的是代碼的可讀性提升和二義性減少，而壞處也是顯而易見的：對於大部分有想法的程式員而言這種規定太死板，容易引起抵觸心理，產生不安定因素。這種情況常見於各種標準的外包公司。

而如果大部分的規範設定為推薦執行，在沒有良好的引導下，規範容易被忽視。 網上有很多關於ObjC的代碼規範，比如蘋果自家的規範和《Google Objective-C Style Guide》等。這些規範一般只有兩種分級:推薦和不推薦。而我更推薦把代碼規範分成五個等級：強制要求，強烈推薦(但不強制)，良好，可接受和不可接受。

以下僅舉部分例子加以說明。

 

符合蘋果規範的命名方式

l 類名開頭大寫，方法和變數名以駝峰法命名。強烈要求，這沒有什麼好說的，蘋果系統類別庫和絕大多數的第三方開源庫都是如此。但在部分蘋果的sample中也看到過用m做首碼表示類成員變數的寫法，這些都是屬於遺產代碼的問題，仍舊是可接受範圍，但是自己代碼內部使用類似匈牙利的命名法就是不可接受。

l 類名使用至少三個字元做首碼，內部方法使用兩個底線做首碼。強烈推薦。上面的做法可以最大程度避免和系統類別庫發生重名的情況：因為蘋果宣稱保留所有兩位字元首碼的使用權，同時其內部方法命名以一個底線做首碼。

l 無論使用K&R Style還是Allman Style都是可接受的範圍，但是強烈推薦在一個檔案內保持一種形式。

l 在保證代碼可讀性的基礎上保持代碼的簡短和統一性：小類，小方法，統一的函數返回。小類，小方法可以保證他人閱讀時更方便地關注類邏輯，而不是具體細節，而統一的函數返回可以減少意外錯誤和降低錯誤排查的難度。而保證代碼的簡短和不羅嗦也是很重要一點，經常會看到如下代碼：  if (count > 1) { return YES; } { return NO; }，真心無法直視。

 

良好的代碼/工程結構

l 為整個工程建立worksapce。

l 按照權責分門別類存放資源檔：每種類型的資源存放於獨立的目錄下：圖片，聲音，設定檔等等。而圖片又可以按照類型分別存放在不同的子目錄下：全域類型，背景圖，logo，登入等等。

l 合理的代碼結構。推薦如下的工程目錄結構。

 

Core：工程內一些通用的機制實作類別：統一的任務管理，模組管理，服務管理。

General：公用類和方法，包括工程內ViewController,UITableViewCell基類(Base)，公用Category(Category)，公用UI組件(CustomUI)，公用輔助方法(Helper)和宏定義(Marco)。

Model：公用資料模型

Sections：不同程式單元。如登入，設定等等。其下又可以按照功能分成不同的子目錄：當前單元使用的自訂UI組件，管理類，資料模型和ViewController等等。

Vendors：第三方庫。

 

《iOS App開發的那些事兒》第二篇文章將會向大家介紹什麼是合適的架構，如何搭建合適的架構，歡迎大家積極發表自己的看法，與我們共同討論。

 

iOS App開發的那些事兒1：如何建立合適的規範