《iOS App開發的那些事兒》系列文章從更宏觀的角度出發，不僅僅局限于具體某個功能、界面的實現，而是結合網易云信iOS端研發負責人多年的經驗，從如何優化現有代碼的角度出發，深度分析如何創造出iOS

App開發中比較合適的規范和框架。

推薦閱讀

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

將代碼規范合理分級

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

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

而如果大部分的規范設定為推薦執行，在沒有良好的引導下，規范容易被忽視。網上有很多關于ObjC的代碼規范，比如蘋果自家的規范和《Google

Objective-C Style Guide》等。這些規范一般只有兩種分級:推薦和不推薦。而我更推薦把代碼規范分成五個等級：強制要求，強烈推薦(但不強制)，良好，可接受和不可接受。

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

符合蘋果規范的命名方式

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

[if !supportLists]l? [endif]類名使用至少三個字符做前綴，內部方法使用兩個下劃線做前綴。強烈推薦。上面的做法可以最大程度避免和系統類庫發生重名的情況：因為蘋果宣稱保留所有兩位字符前綴的使用權，同時其內部方法命名以一個下劃線做前綴。

[if !supportLists]l? [endif]無論使用K&R Style還是Allman Style都是可接受的范圍，但是強烈推薦在一個文件內保持一種形式。

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

良好的代碼/工程結構

[if !supportLists]l? [endif]為整個工程創建worksapce。

[if !supportLists]l? [endif]按照權責分門別類存放資源文件：每種類型的資源存放于獨立的目錄下：圖片，聲音，配置文件等等。而圖片又可以按照類型分別存放在不同的子目錄下：全局類型，背景圖，logo，登錄等等。

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

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

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

Model：公用數據模型

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

Vendors：第三方庫。

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

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯系，并提供相關證據，工作人員會在5工作日內聯系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.juherenli.com/12176.html