iOS App开发的那些事儿1：如何建立合适的规范
《iOS App開發的那些事兒》系列文章從更宏觀的角度出發，不僅僅局限于具體某個功能、界面的實現，而是結合網易云信iOS端研發負責人多年的經驗，從如何優化現有代碼的角度出發，深度分析如何創造出iOSApp開發中比較合適的規范和框架。
?
推薦閱讀
iOSApp開發的那些事兒2：如何搭建合適的框架
?
將代碼規范合理分級
大家都理解軟件開發需要合適的規范：代碼規范，程序規范，流程規范等等，以此來減少意外的出現：最少驚訝原則。但在實際執行中卻會碰到各種情況，其中最大的問題是：怎么鑒別哪些規范是需要強制執行，哪些規范是推薦執行。
規范的強制執行帶來的是代碼的可讀性提升和二義性減少，而壞處也是顯而易見的：對于大部分有想法的程序員而言這種規定太死板，容易引起抵觸心理，產生不安定因素。這種情況常見于各種標準的外包公司。
而如果大部分的規范設定為推薦執行，在沒有良好的引導下，規范容易被忽視。網上有很多關于ObjC的代碼規范，比如蘋果自家的規范和《GoogleObjective-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，登錄等等。
- 合理的代碼結構。推薦如下的工程目錄結構。
Core：工程內一些通用的機制實現類：統一的任務管理，模塊管理，服務管理。
General：公用類和方法，包括工程內ViewController,UITableViewCell基類(Base)，公用Category(Category)，公用UI組件(CustomUI)，公用輔助方法(Helper)和宏定義(Marco)。
Model：公用數據模型
Sections：不同程序單元。如登錄，設置等等。其下又可以按照功能分成不同的子目錄：當前單元使用的自定義UI組件，管理類，數據模型和ViewController等等。
Vendors：第三方庫。
?
《iOS App開發的那些事兒》第二篇文章將會向大家介紹什么是合適的框架，如何搭建合適的框架，歡迎大家積極發表自己的看法，與我們共同討論。
總結
以上是生活随笔為你收集整理的iOS App开发的那些事儿1：如何建立合适的规范的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android 即时通讯开发小结（二）
- 下一篇： 移动IM开发指南1：如何进行技术选型