命名原則

1.基本原則

（1）清晰。 命名應該是以清晰為主、簡潔為輔。總的來講不要使用單詞的簡寫，除了使用非常常見的簡寫以外，盡量使用單詞的全稱。不可使用拼音、數字、容易讓人看不懂易混淆的詞命名。自定義API（造輪子）時，API的名稱不要有歧義并且不要與蘋果原生API產生沖突，讓使用者一看你的API就知道是以什么方式用來做什么的。

（2）一致性。 本項目采用XFB作為類前綴，對于通知的名稱也應采用XFB為前綴Notification為尾綴，宏定義應以k為前綴，對于枚舉常量方法名的定義參考蘋果原生API，總體來講所有命名都應盡可能的與蘋果API保持一致。

2.類命名

類名應該遵循駝峰命名原則。類名中應該包含一個或多個單詞來描述這個方類（或類對象）是做什么的。

3.類別命名

類名+個人標識+拓展名

例如UIView+YPExtension

類別的方法應該使用個人標識前綴加下劃線加方法名避免與項目中的其他方法產生沖突。詳情參考SDWebImage的sd_setImage：方法...

4.方法命名

方法使用小駝峰法命名, 一個規范的方法讀起來應該像一句完整的話，讀過之后便知函數的作用。執行性的方法應該以動詞開頭，小寫字母開頭，返回性的方法應該以返回的內容開頭，但之前不要加get。如果有參數，函數名應該作為第一個參數的提示信息，若有多個參數，在參數前也應該有提示信息（一般不必加and）一些經典的操作應該使用約定的動詞，如initWith,insert,remove,replace,add等等。

5.變量命名

（1）變量名使用小駝峰命名規則，使變量名盡可能可以推測其用途。

（2）類的成員變量用小駝峰命名法并加上下劃線開頭的方式命名。

（3）一般變量命名請使用簡潔明了的方式并且開頭不要使用下劃線。

6.常量命名

常量(預定義，枚舉，局部常量等)使用小寫k開頭的駝峰法。

7.圖片資源文件命名

先看下新浪微博app圖片資源命名方式，下面是部分截圖：

圖片發自簡書App

圖片發自簡書App

這個圖片資源命名方式，以功能為組織形式，是一個很好的習慣，有利于查看資源文件。
原則：
1）采用單詞全拼，或者大家公認無岐義的縮寫(比如：nav，bg，btn等)
2）采用“模塊+功能”命名法，模塊分為公共模塊、私有模塊。公共模塊主要包括統一的背
景，導航條，標簽，公共的按鈕背景，公共的默認圖等等；私有模塊主要根據app的業務
功能模塊劃分，比如用戶中心，消息中心等

備注：建議背景圖采用以bg作前綴，按鈕背景采用btn作前綴（不作強制要求，項目實際
負責人根據團隊特點確定即可）

公共模塊命名示例：
導航條背影圖片：bg_nav_bar@2x.png
導航返回按鈕：bg_nav_back_normal@2x.png，bg_nav_back_selected@2x.png
標簽item背景：bg_tabbar_record_normal@2x.png，bg_tabbar_record_selected@2x.png

私有模塊命名示例：
以Joggers APP的用戶中心圖片資源為例說明，
uc——user center
用戶中心頭像默認圖：bg_uc_avatar@2x.png
用戶中心頂部默認背景圖：bg_uc_top_defaut@2x.png
用戶中心底部背景圖：bg_uc_bottom@2x.png

文件組織結構

1.類文件組織

iOS工程文件結構分物理結構和邏輯結構，建議邏輯結構和物理結構保持一致，以便方便有效地管理類文件。類文件組織要遵循以下兩大原則：
基于MVC設計模式原則，至少要保證controller與數據處理，網絡請求相對獨立基于功能模塊原則，功能模塊分包括數據/網絡處理，UI前端界面兩部分，數據/網絡處理應該在數據/網絡處理的框架下，而UI前端界面比如用戶中心，消息中心，它們的專有的controller，view等應該在屬于文件夾。還會遇到一些公共的view，可以開辟出公共的文件夾來管理。

2.圖片資源文件組織

圖片資源文件采用Images.xcassets管理，不要使用自己創建的文件夾管理。

代碼規范

1.刪除多余的空行

（1） 所有方法與方法之間空1行

（2）所有代碼塊之間空1行

2.刪除多余的注釋

（1）刪除注釋掉的代碼

（2）刪除沒有意義的注釋

3.刪除多余的方法

（1）如果方法沒有使用到，請刪除它

（2）如果方法沒有執行任何業務邏輯，請刪除它或者給出一定注釋

4.刪除未被使用的資源文件
5.添加必要的注釋

（1）所有 .h 文件中的property 需要給出注釋

（2）所有自定義的方法需要給出注釋

（3）比較大的代碼塊需要給出注釋

（4）所有代碼中出現的阿拉伯數字需要給出注釋

（5）程序中出現加密／解密 邏輯的操作地方，需要給出注釋說明過程（無論是系統還是自定義）

6.整體代碼風格需要統一

（1）代碼后面的”{“ 不需要單獨占用一行

（2）邏輯運算符 與 代碼之前空一格

? ? * “#pragma mark -” 與下面的代碼之前不要空行

（3）遵循一般性的代碼規范

通用規則

1 下面所有規則對第三方類庫無約束
? ? * 所有類、方法、屬性等命名，做到見名知意，采用駝峰式命名規則
? ? * 根據資源類型或者所屬業務邏輯對項目資源進行分組，使得整個項目結構清晰明了
? ? * 整個項目保持一種代碼書寫風格（這個風格由無錫團隊根據自己編碼習慣來定），讓你的代碼變的優雅！
2. 命名規范
? ? * 所有類名稱以項目工程開頭命名，eg：“XP”、“ZJG”、“SZ”
? ? * 針對不同視圖控制器，在末尾添加后綴，eg：
? ? * UIViewController ?后綴添加“ViewController”
? ? * UIView 后綴添加“View”
? ? * UIButton 后綴添加“Button"
? ? * UILabel 后綴添加“Label"
3. 單頁代碼最好控制在800行以內，每個方法最好不要超過100行，過多建議對代碼進行重構
4. 相同的邏輯方法定義避免在多個地方出現，盡量將公用的類、方法抽取出來
5. 刪除未被使用的代碼，不要大片注釋未被使用的代碼，確定代碼不會使用，請及時刪除
6. 對其他項目中copy過來的代碼，根據具體需要更新代碼風格，及時刪除未被使用的代碼
7. 項目中所有Group或者文件名稱（圖片名字等），不要使用漢字命名，盡量使用英文命名，國內特有名詞可以使用拼音。
8. 項目中所有Group都需要在項目目錄中存在一個真實的目錄，Group中的文件與真實目錄中文件一一對應。
9. 請在項目中寫必要代碼的注釋
10. 請多使用 #pragma mark - Mark Name 對方法進行分組 eg:
? ? * #pragma mark - View lifeCycle
? ? * #pragma mark - View lifeTerm
? ? * #pragma mark - Init methods
? ? * #pragma mark - Action methods
? ? * #pragma mark - Common methods
? ? * #pragma mark - UIActionSheetDelegate
? ? * #pragma mark - UIImagePickerControllerDelegate
? ? * #pragma mark - UITableViewDelegate Methods
? ? * #pragma mark - UITableViewDataSource Methods
? ? * #pragma mark - UIScrollViewDelegate Methods
? ? * #pragma mark - UITextFieldDelegate Methods
? ? * #pragma mark - UITextViewDelegate Methods