下面總結一下OC編程中的一些代碼規范(蘋果官方推薦的)。以OC為示例，但不局限於OC，也可以被當作別的編程語言的開發規范約定(僅需要把OC特有的東西按照你所使用的語言的慣例即可)

 

命名

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

本文推薦駝峰法，也是Objective-C社區的標准。

駝峰法分小駝峰法和大駝峰法。小駝峰法：除第一個單詞之外，其他單詞首字母大寫。大駝峰法相比小駝峰法，大駝峰法把第一個單詞的首字母也大寫了。

1.基本原則

1.1 清晰

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

1.2 一致性

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

2. 類命名

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

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

 

示例1：

@interfaceImageBrowseView :UIView

@end

 

示例2：（帶前綴JK）

@interfaceJKPhotoBrowser :UIView

@end

 

3. 類別命名

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

例：如果我們想要創建一個基於UIImageView 的類別用於網絡請求圖片，我們應該把類別

放到名字是UIImageView+HPWeb.h的文件裡。UIImageView為要擴展的類名，HP為專屬標

識，Web為擴展的功能。

類別的方法應該都使用一個前綴(型如hp_myCategoryMethodOnAString ),以防止Objective-

C代碼在單名空間裡沖突。如果代碼本來就不考慮共享或在不同的地址空間(address-

space)，方法命名規則就沒必要恪守了。

 

類別HPWeb頭文件，UIImageView+HPWeb.h如下：

@interfaceUIImageView (HPWeb)

 

- (void)hp_setImageWithURLString:(NSString*)urlStr;

 

@end

4. 方法命名

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

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

開頭，但之前不要加get。

示例：

- (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;

(instancetype)arrayWithArray:(NSArray*)array;

 

如果有參數，函數名應該作為第一個參數的提示信息，若有多個參數，在參數前也應該有

提示信息（一般不必加and）

一些經典的操作應該使用約定的動詞，如initWith,insert,remove,replace,add等等。

5. 變量命名

變量名使用小駝峰法, 使變量名盡量可以推測其用途屬性具有描述性。別一心想著少打幾

個字母，讓你的代碼可以迅速被理解更加重要。

5.1 類成員變量：

成員變量用小駝峰法命名並前綴下劃線，Objective-C 2.0，@property 和 @synthesize 提供

了遵守命名規范的解決方法

 

示例：

@interfaceViewController()

@property(nonatomic,strong)NSMutableArray *dataArray;

@property(nonatomic,strong)UITableView *tableView;

@end

 

@implementationViewController

 

@end

 

5.2 一般變量命名

 

示例：

 

NSMutableArray *ticketsArray = [NSMutableArrayarrayWithCapacity:0];

NSIntegernumCompletedConnections =3;

 

 

5.3 常量命名

 

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

kWritePerm

 

示例：

#define kRunAnnotationStartPointTitle @“起點"

 

typedefNS_ENUM(NSInteger,RunGoalTypeE){

kRunGoalTypeNone =0, //無目標

kRunGoalTypeTime =1, //以時間為目標

kRunGoalTypeDistance =2, //以距離為目標

kRunGoalTypeCalori =3, //以消耗卡路裡為目標

};

 

NSString*constkGroupInfoName =@"name";

 

6. 圖片資源文件命名

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

 

 

這個圖片資源命名方式，以功能為組織形式，是一個很好的習慣，有利於查看資源文件。

原則：

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

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

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

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

 

備注：建議背景圖采用以bg作前綴，按鈕背景采用btn作前綴（不作強制要求，項目實際

負責人根據團隊特點確定即可）

 

公共模塊命名示例：

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

導航返回按鈕：[email protected]，[email protected]

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

 

私有模塊命名示例：

以Joggers APP的用戶中心圖片資源為例說明，

uc——user center

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

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

用戶中心底部背景圖：[email protected]

 

這部分工作較為繁雜，並且在程序員心中會認為是技術含量較低的一個工作，但圖片命名

的嚴謹性同樣會反映出我們對細節的追求，細節決定成敗。

文件組織結構

1. 類文件組織

iOS工程文件結構分物理結構和邏輯結構，建議邏輯結構和物理結構保持一致，以便方便有效地管理類文件。類文件組織要遵循以下兩大原則：

基於MVC設計模式原則，至少要保證controller與數據處理，網絡請求相對獨立

基於功能模塊原則，功能模塊分包括數據/網絡處理，UI前端界面兩部分，數據/網絡處理應該在數據/網絡處理的框架下，而UI前端界面比如用戶中心，消息中心，它們的專有的controller，view等應該在屬於文件夾。還會遇到一些公共的view，可以開辟出公共的文件夾來管理

在實際中使用中，項目實際負責人可以結合項目特點靈活使用，但基本的原則一定要保持，保持良好的類文件組織結構，對團隊有益無害。

2. 圖片資源文件組織

圖片資源文件，強烈建議采用Images.xcassets管理，盡量少用自己創建的文件夾管理。

使用Images.xcassets的優勢很多，具體可以查閱讀相關文獻資料，這裡只從工程管理上說一點，在Images.xcassets中添加圖片資源，不會對project文件造成改變，而直接在文件夾裡添加圖片文件，每次都會對project文件造成改變，因此使用Images.xcassets管理圖片資源可以減少project沖突的次數。

下圖是Joggers的文件組織結構：

 

 

上圖嚴格按照上述討論組織文件結構，保持了物理/邏輯結構的統一，方便團隊間查閱代

碼，以及共享資源。

類代碼組織原則

一個原則：析構函數- (void)dealloc最好放到類最上面，第一眼就可以看到這個方法，可以方便看到是否remove了一些操作，對內存的合理釋放等，controller，view的生命周期函數放到最上面，自己實現的方法在下面，相同/相近功能的方法采用#pragma mark -來標記，以便查看。

示例：

 

第一部分主要對易把握的，易推廣的，並且對團隊開發中有實實在在幫助內容作簡要論述，主要集中在命名，文件組織原則方面，並給了相應的示例。規范由各項目負責人具體執行。好像忘記一件什麼事，沒錯，注釋，上述沒有對注釋做專門的闡述，良好的代碼習慣就是一個好的注釋，因此這裡不專門為注釋作討論，注釋要求由各項目負責人來約定。

 

@傅總 團隊要求

iOS代碼規范


1 刪除多余的空行
* 所有方法與方法之間空1行
* 所有代碼塊之間空1行
2 刪除多余的注釋
* 刪除注釋掉的代碼
* 刪除沒有意義的注釋
3 刪除多余的方法
* 如果方法沒有使用到，請刪除它
* 如果方法沒有執行任何業務邏輯，請刪除它或者給出一定注釋
4 刪除未被使用的資源文件
5 添加必要的注釋
* 所有 .h 文件中的property 需要給出注釋
* 所有自定義的方法需要給出注釋
* 比較大的代碼塊需要給出注釋
* 所有代碼中出現的阿拉伯數字需要給出注釋
* 程序中出現加密／解密 邏輯的操作地方，需要給出注釋說明過程（無論是系統還是自定義）
6 整體代碼風格需要統一
* 代碼後面的”{“ 不需要單獨占用一行
* 邏輯運算符 與 代碼之前空一格
* “#pragma mark -” 與下面的代碼之前不要空行
* 遵循一般性的代碼規范


iOS通用規則


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