1. 前言：
命名規則對于維護代碼來說是非常重要的,Objective-C方法名往往很長，不過這也有好處，可以更清晰地理解和直觀理解方法，甚至無須過多的注釋；
1.基本原則
1.0：代碼清晰
又清晰又簡潔的代碼當然是最好的了，但簡潔不如清晰重要。總的講不要使用單詞的簡寫，除了非常常用的簡寫以外，盡量使用單詞全稱。API的名稱不要有歧義，一看你的API就知道是以什么方式做了什么事情，不要讓人有疑問！
1.1：一致性
代碼保持一致，例如：創建UI相關的方法,可以使用統一的方法命名，所見即所得，見表知其意，這樣，既保證了代碼的一致性，也可以方便我們后續維護和管理，也利于團隊代碼風格的一致，協調！
2.類命名
2.1：命名規范
小駝峰命名法：第一個單字以小寫字母開始；第二個單字的首字母大寫，如：testClass
大駝峰命名法：每一個單字的首字母都采用大寫字母，如：
TestClass
類命名：
首字母大寫，之后每個單詞首字母都大寫
使用能夠反映類功能的名詞短語
文件和類同名
舉例：BaseClient .h、ImageStore .h
特殊類命名
如果是視圖控制器的子類應添加后綴“ViewController”或者“Controller”
如果是視圖的子類應添加后綴“View”
如果是按鈕的子類應添加后綴“Button”
等……
舉例：SettingsViewController、NavigationView
分類（類別）命名
與類命名相同，此外需添加要擴展的類名和“+”
舉例：NSString+URLEncoding
協議（委托）命名
與類命名相同，此外需添加“Delegate”后綴
舉例：ReplyViewDelegate
方法命名
首字母小寫，之后每個單詞首字母都大寫
方法名使用動詞短語
舉例：- (void)setPostValue:(int)value
方法參數命名
首字母小寫，之后每個單詞首字母都大寫
具有足夠的說明性
不需要添加類型前綴
舉例：- (void)sendUserInfo:(NSDictionary *)userInfo
常量
常量（宏定義，局部常量等）使用小寫k開頭的駝峰法
舉例：kInvalidHandle , kWritePerm
枚舉類型命名首字母大寫，之后每個單詞首字母都大寫，最后加“s”
枚舉變量使用枚舉類型去掉“s”作為前綴，每個單詞首字母大寫，中間不允許加下劃線
舉例：typedef enum UIControlEvents{
UIControlEventTouchDown,
UIControlEventTouchUpInside
}UIControlEvents;
分組命名
使用英文，首字母大寫，之后每個單詞首字母都大寫
每個分組使用模塊的名字
使用的開源庫統一放在“Library”分組下
使用的公共組件統一放在“Common”分組下
視圖控制器及AppDelegate統一放在“Controllers”分組下
2.2：類注釋規范
一.類的聲明：
/** 類信息。此注釋用在類聲明的開頭。
@class
@abstract 這里可以寫關于這個類的一些描述。
*/
示例1：
/** 類信息。此注釋用在類聲明的開頭。
@TestClass
@這是一個測試類
*/
@interface TestClass :UIView
@end
二：變量的聲明
/**
@property property的相關注釋。
@abstract 這里可以寫關于這個Property的一些基本描述。
*/
示例2：
/**
* name:這是一個名字；
*/
@property (nonatomic,copy) NSString * name;
三：方法的聲明
/**
@method 函數(方法)的相關注釋。
@abstract 這里可以寫一些關于這個方法的一些簡要描述
@discussion 這里可以具體寫寫這個方法如何使用，注意點之類的。
如果你是設計一個抽象類或者一個共通類給給其他類繼承的話，建議在這里具體描述一下怎樣使用這個方法。
@param text 文字(這里把這個方法需要的參數列出來)
@param error 錯誤參照
@result 返回結果
*/
示例3：
/**
* 這是個請求數據方法；
* result : (NSObject*) 數據返回結果；
* block :( doBlock)block 代碼塊，返回結果需要完成的事；
*/
-(void)doRequestResult:(NSObject*)result andSuccessBlock:(doBlock)block ;
2.3：書寫規范
文件都包含文件頭，要說明文件名、作者、創建時間、變更記錄
多人協作完成項目時，public接口的每個方法都應該添加關于函數，參數，返回值以及副作用的注釋
當if語句的判斷條件復雜時，需要用注釋說明判斷內容
接口類（繼承于BaseController）的頭文件每個方法前都應該注明方法的作用
3.文件組織結構
3.1:類文件組織
iOS工程文件結構分物理結構和邏輯結構，建議邏輯結構和物理結構保持一致，以便方便有效地管理類文件。
類文件組織要遵循以下兩大原則：
基于MVC設計模式原則，至少要保證controller與數據處理，網絡請求相對獨立
基于功能模塊原則，功能模塊分包括數據/網絡處理，UI前端界面兩部分，數據/網絡處理應該在數據/網絡處理的框架下，
而UI前端界面比如用戶中心，消息中心，它們的專有的controller，view等應該在屬于文件夾。
還會遇到一些公共的view，可以開辟出公共的文件夾來管理。
在實際中使用中，項目實際負責人可以結合項目特點靈活使用，
但基本的原則一定要保持，保持良好的類文件組織結構，對團隊有益無害。
3.2：圖片資源文件組織
圖片資源文件，強烈建議采用Images.xcassets管理，
盡量少用自己創建的文件夾管理。
使用Images.xcassets的優勢很多，具體可以查閱讀相關文獻資料，這里只從工程管理上說一點，在Images.xcassets中添加圖片資源，
不會對project文件造成改變，而直接在文件夾里添加圖片文件，每次都會對project文件造成改變，
因此使用Images.xcassets管理圖片資源可以減少project沖突的次數
3.3：類代碼組織原則
一個原則：
1.析構函數-
(void)dealloc最好放到類最上面，第一眼就可以看到這個方法，
可以方便看到是否remove了一些操作，對內存的合理釋放等。
2.controller，view的生命周期函數放到最上面
3.自己實現的方法在下面，相同/相近功能的方法采用#pragma
mark -來標記，以便查看。
4. iOS代碼規范
4.1:團隊規范
說明：一個好的團隊，理所當然有其嚴格的代碼規范，好的代碼不僅可以提高團隊的開放效率，也更利于團隊項目的后期維護，統一的代碼風格，也是團隊的核心，所以規范代碼很有必要！
**
1 刪除多余的空行
所有方法與方法之間空1行
所有代碼塊之間空1行
2 刪除多余的注釋
刪除注釋掉的代碼
刪除沒有意義的注釋
3 刪除多余的方法
如果方法沒有使用到，請刪除它
如果方法沒有執行任何業務邏輯，請刪除它或者給出一定注釋
4 刪除未被使用的資源文件
5 添加必要的注釋
所有.h 文件中的property 需要給出注釋
所有自定義的方法需要給出注釋
比較大的代碼塊需要給出注釋
所有代碼中出現的阿拉伯數字需要給出注釋
程序中出現加密／解密 邏輯的操作地方，需要給出注釋說明過程（無論是系統還是自定義）
6 整體代碼風格需要統一
代碼后面的”{“
不需要單獨占用一行
邏輯運算符 與 代碼之前空一格
“#pragma mark -” 與下面的代碼之前不要空行
遵循一般性的代碼規范
4.2 iOS通用規范
1 下面所有規則對第三方類庫無約束
* 所有類、方法、屬性等命名，做到見名知意，采用駝峰式命名規則* 根據資源類型或者所屬業務邏輯對項目資源進行分組，使得整個項目結構清晰明了
* 整個項目保持一種代碼書寫風格（這個風格由團隊根據自己編碼習慣來定），讓你的代碼變的優雅！
2. 命名規范
* 所有類名稱以項目工程開頭命名，：“QMX”、“SX”、“CS”,”PF”等···；
* 針對不同視圖控制器，在末尾添加后綴，
* 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 對方法進行分組
5.版權聲明
該規范為iOS開發人員共同代碼規范，共同維護開發，
如有更好的建議，歡迎在此基礎上進行修改并在版本歷史記錄中添加修改內容,謝謝
