一、命名規范

命名規則對於維護代碼來說是非常重要的,。Objective-C方法名往往很長，不過這也有好處，讓很多注釋變得毫無意義。

1、駝峰法

Objective-C社區的標准，駝峰法分小駝峰法和大駝峰法。小駝峰法：除第一個單詞之外，其他單詞首字母大寫，一般用於變量命名。大駝峰法相比小駝峰法，大駝峰法把第一個單詞的首字母也大寫了，一般用於對象命名。

2、基本原則

1） 清晰（可讀性高）

又清晰又簡潔是最好的了，但簡潔不如清晰重要。總的講不要使用單詞的簡寫，除了非常常用的簡寫以外，盡量使用單詞全稱。API的名稱不要有歧義，一看你的API就知道是以什麼方式做了什麼事情，不要讓人有疑問

2） 一致性

做某個事情代碼通常都叫這個名字，比如tag、setStringValue，那麼你也這麼叫。你在不確定怎麼起名字的時候，可以參考一些常用的名字：Method Arguments

3）禁止使用中文或拼音（英文不好？ 有道一下啦）

3. 類命名

類名(不包括類別和協議名)應該用大寫開頭的大駝峰命名法。類名中應該包含一個或多個名詞來說明這個類（或者類的對象）是做什麼的。

在應用級別的代碼裡，盡量不要使用帶前綴的類名。每個類都有相同的前綴不能提高可讀性。不過如果是編寫多個應用間的共享代碼，前綴就是可接受並推薦的做法了(型如 MWPhotoBrowser )。

4. 類別命名（Category）

類名+標識+擴展（UIImageView +HP+Web）

類別的方法應該都使用一個前綴(型如hp_myCategoryMethodOnAString ),以防止Objective-C代碼在單名空間裡沖突。如果代碼本來就不考慮共享或在不同的地址空間(address-space)，方法命名規則就沒必要恪守了。

5. 方法命名

方法使用小駝峰法命名, 一個規范的方法讀起來應該像一句完整的話，讀過之後便知函數

的作用。執行性的方法應該以動詞開頭，小寫字母開頭，返回性的方法應該以返回的內容

開頭，但之前不要加get。

6. 變量命名

1）變量名使用小駝峰法, 使變量名盡量可以推測其用途屬性具有描述性。必須起有意義的名字，使其他組員可以很容易讀懂變量所代表的意義，變量命名可以采用同義的英文命名，可使用幾個英文單詞。別一心想著少打幾個字母，讓你的代碼可以迅速被理解更加重要。

2）對於一些特殊類型的變量，命名時要帶上類型，如NSArray 的變量命名為xxxArray 或xxxList，其他的如xxxDictionary，xxxSize等。這樣就可以從名稱上知道是什麼類型的變量。千萬不能將NSArray的變量命名為xxxDictionary。

3）對於UI控件變量，命名時後綴要以特定的控件名。

如：@property (weak, nonatomic) IBOutlet UILabel *versionLabel;

4）控制器的後綴必須加ViewController， 名字過長的情況下也必須加上Controller作為後綴；

5） 普通View後綴必須加View，UITableViewCell和UICollectionViewCell後綴必須加Cell；

6）成員變量命名，盡量采用@property方式來申明變量，如果不用@property方式申明變量，則必須采用前綴下劃線來申明變量

7. 常量命名

1）對於常量的命名最好在前面加上字母k作為標記. 如:

static const NSTimeInterval kAnimationDuration = 0.3;

2）定義作為NSDictionary或者Notification等的Key值字符串時加上const關鍵字, 以防止被修改，通知的name一定要以Notification作為後綴。如:

NSString *const UIApplicationDidEnterBackgroundNotification

3） 避免在程序中直接出現常數，使用超過一次的應以宏定義的形式來替代。

8. 枚舉命名

枚舉類型命名要加相關類名前綴並且枚舉值命名要加枚舉類型前綴.

typedef NS_ENUM(NSInteger, UIViewAnimationTransition) {

UIViewAnimationTransitionNone,

UIViewAnimationTransitionFlipFromLeft,

UIViewAnimationTransitionFlipFromRight,

UIViewAnimationTransitionCurlUp,

UIViewAnimationTransitionCurlDown,

};

9. 圖片資源文件命名

原則：

1）采用單詞全拼，或者大家公認無岐義的縮寫(比如：nav，bg，btn等)

2）采用“模塊+功能”命名法，模塊分為公共模塊、私有模塊。公共模塊主要包括統一的背

景，導航條，標簽，公共的按鈕背景，公共的默認圖等等；私有模塊主要根據app的業務

功能模塊劃分，比如用戶中心，消息中心等

注：Assets.xcassets中文件夾必須分模塊，命名必須小寫，圖片必須命名好之後再放入Assets.xcassets中。通常來說，Assets中至少包含common，tabbar，navigation這三個模塊。

公共模塊命名示例：

背景圖采用以bg作後綴綴，按鈕背景采用btn作後綴;

導航條背影圖片：[email protected]

導航返回按鈕：[email protected]

標簽item背景：[email protected]，[email protected]

通用cell占位圖：[email protected]

私有模塊命名示例：

以用戶中心圖片資源為例說明：

用戶中心頭像默認圖：[email protected]

用戶中心頂部默認背景圖：[email protected]

9. 目錄命名

用英文命名時，首字母大寫，可以用中文命名，但是禁止使用拼音命名。

二、編碼排版格式

1、代碼的縮進應使用空格（SPACE），不能使用制表符（TAB），並且縮進以2個 字符為單位。快捷方式：Command + A —— > Control + I

2、 中括弧的每一個括弧在源程序中要單獨占一行。

3、 空格的使用

a) 關鍵字與其後的表達式之間要有空格

b) 單目操作符不應與它們的操作數分開（如’!’和’^’等）。

c) 除’ , ’外，其它雙目操作符應與它們的操作數用空格隔開。

d) .h中協議<>前面有一個空格。

e) .h中成員聲明時，類型與變量之間有至少1個空格。*號靠近變量，不靠近類型。

f) @property後留1個空格，（）裡面，逗號緊跟前一變量，與後一變量之間留1 個空格。（）外面，先留1個空格，再聲明屬性。

g) 方法的+，-後面與（）之間留1個空格。

h) 返回類型與*之間留1個空格，方法參數中返回類型與*之間留1個空格。

i) 在多參數方法中，每個參數後面都有1個空格。

4、 每行只能有一個語句

5、關於空行

a) .h中的空行

• 1、文件說明與頭文件包含(#import)之間空1行
• 2、頭文件包含(#import)之間，如果需要分類區別，各類別之間空1行。
• 3、頭文件包含(#import)與@class之間空2行。
• 4、@interface與@class之間空1行。
• 5、頭文件{}裡面，空1行開始聲明對象成員，如果需要分類區別，各類別之間空1行。
• 6、頭文件{}外，空1行書寫屬性，如果需要分類區別，各類別之間空1行。
• 7、屬性下面空1行開始寫方法，如果需要分類區別，各類別之間空1行。
• 8、方法完成後，空1行@end。
• 9、如果需要聲明protocol，空2行接著寫。通常protocol寫在@end後面，但是聲明在@interface之前。

  b) .m中的空行

• 1、文件說明與頭文件包含(#import)之間空1行
• 2、頭文件包含(#import)之間，如果需要分類區別，各類別之間空1行。
• 3、@implementation和@synthesize之間空1行, 如果需要分類區別，各類別之間空1行。
• 4、方法與方法之間空1行。

  c) 方法裡面的空行

• 1、變量聲明後需要空1行，如果需要分類區別，各類別之間空1行。
• 2、條件、循環，選擇語句，整個語句結束，需要空1行。
• 3、各功能快之間空1行。
• 4、最後一個括弧之前不空行。
• 5、注釋與代碼之間不空行。
• 6、#pragma mark 與方法之間空1行。

d) 每行代碼最多不得操作100個字。設置如下：Xcode => Preferences => TextEditing => Page Guide at column /輸入 100即可。

6、注釋

1、變量名、方法名等不足以說明實際意義的時候，必須要寫注釋；

2、類名不足以提現類的作用的時候，必須在類聲明的上面添加注釋，說明類的基本作用。

3、可能涉及到注釋的地方主要包括：

類注釋、方法注釋、成員變量注釋、枚舉注釋、宏定義注釋、宏定義方法注釋、邏輯注釋、Protocol注釋

4、推薦使用VVDocumenter

7、文件夾：所有新建的目錄，在工程下必須存在實體目錄；

8、單頁面代碼不得超過800行，單個方法不得超過50行。

3 、規定

1、 dealloc方法 規定：一個類的dealloc方法如果有必要存在，必須是.m中的最後一個方法，方便查找；

2、非特殊需要，不允許將UI控件的property直接創建到.h文件中；

3、當需要一定條件才執行某項操作時，最左邊的應該是最重要的代碼，不要將最重要的代碼內嵌到if中。

如良好的風格是：

- (void) someMethod {

if(![someOther boolValue]) {

return;

}

//最重要的代碼寫在這裡；

}

反面教材：

- (void) someMethod {

if([someOther boolValue]) {

//重要代碼；

}

}

4 、建議

1、盡量不使用for循環，可用forin或者enumerateObjectsUsingBlock進行遍歷；

2、盡可能保證 .h文件的簡潔性，可以不公開的API就不要公開了，寫在實現文件中即可；

3、建議使用“#pragma mark”，方便閱讀代碼。有些由於數據等方面問題需要以後做處理的使用#pragma warnning”進行提醒;

4、if-else超過四層的時候，就要考慮重構，多層的if-else結構很難維護；

5、UIView的子類初始化的時候，不要進行任何的布局操作。布局操作應該在layoutSubviews裡面做；需要重新布局的時候調用setNeedsLayout，而不要直接調用layoutSubviews。（一般代碼創建的時候這樣做）；

6、推薦方法的第一個花括號直接跟在方法體後，而不是另起一行，這樣可以減少代碼行；

7、方法體中的第一行留空，最後一行不留空，這樣一個方法就會比較清晰，但是如果該花括號裡面又是一個if，for之類的帶花括號的語句塊，那麼上述的第一行可以不留空。

同樣，如果花括號內第一行是注釋的話，第一行也可以不留空。注釋也起到了分隔代碼的作用，看起來比較清晰。

再者，如果花括號內只有一行代碼，第一行可以不留空。du -k repos