命名

Bundle id命名：

規則：采用反域名命名規則，全部使用小寫字母。一級包名為com，二級包名根據應用進行命名。

類命名：

類命采取駝峰命名規則，即首字母必須大寫，如果為詞組，則每個單詞的首字母必須大寫，類名只能使用名詞或名詞詞組；并以項目工程開頭命名，力求類名簡單 。

繼承自UIView的類以View結尾。

繼承自ViewController的類以ViewController 結尾。

保存數據的實體以Model結尾。

方法的命名：

規則：方法名第一個單詞是一個動詞，其首字母小寫，其后的所有單詞首字母大寫。

如：- (void) addNotification{}

類中常用方法命名：

類的獲取方法

如果返回值為單個值，一般在頭部加上單詞“get”。如果返回值是數組或列表，要在頭部加單詞“find”

如：- (NSString*)getUserName{}、- (NSArray*)findFriends{}

類的設置方法

在被訪問字段名的前面加上前綴 set

如：- (void)setName:(NSString *)name{}

類的布爾型判斷方法

一般要求方法名使用單詞 is或has 做前綴

如：isNetWorkConnected（）

構造方法應該用遞增的方式寫。

參數個數少的在前

變量命名

規則：第一個單詞首字母必須小寫，往后的單詞需要符合駝峰命名規則，即第一個字母大寫。變量名盡可能的使用名詞或名詞詞組。同樣要求簡單易懂，不允許出現無意義的單詞。

如：String *userName

其他命名規則

實例變量命名

加前綴“_”

控件變量命名

規則：一般的變量命名后加上控件名稱

IBOutlet UILabel *userNameLabel;

常量命名：

規則：必須全部大寫，單詞間用下劃線隔開。

如：MAP_KEY

異常命名：

規則：自定義異常首字母大寫，以 Exception 為結尾。

如：AppException

資源命名：

項目中所使用的所有資源命名必須以全部單詞小寫，單詞間以下劃線分割，加前綴區分。

原則：

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

2）采用“模塊+功能”命名法，模塊分為公共模塊、私有模塊。公共模塊主要包括統一的背景，導航條，標簽，公共的按鈕背景，公共的默認圖等等；私有模塊主要根據app的業務

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

btn_xx_normal ? ? ? ? ?按鈕正常情況下的效果

btn_xx_press ? ? ? ? ? ? 按鈕點擊下的效果?

bg_head? ? ? ? ? ? ? ? ? ? 背景圖片使用bg_功能_說明

def_search_cell? ? ? ? ? 默認圖片使用def_功能_說明

icon_more_help ? ? ? ? 圖標圖片使用icon_功能_說明

seg_list_line? ? ? ? ? ? ? 具有分割特征的圖片使用seg_功能_說明

sel_ok? ? ? ? ? ? ? ? ? ? ? ? 選擇圖標使用sel_功能_說明

代碼風格

整體代碼風格需要統一

Import

Import語句引入的次序如下：

IOS imports

第三方庫

自定義.h文件

在每組內部按字母排序，大寫字母排在小寫字母的前面。每個大組之間應該空一行。

空格

1. 關鍵字與其后的表達式之間需要加空格。

2. 單目操作符不應與操作數分開。

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

4. 在.h中協議<>前面有一個空格。

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

6. @property后留1個空格，（）里面，逗號緊跟前一變量，與后一變量之間留1 個空格。（）外面，先留1個空格，再聲明屬性。

7. 方法的+，-后面與（）。

8. 返回類型與*之間留1個空格，方法參數中返回類型與*之間留1個空格

9. 在多參數方法中，每個參數后面都有1個空格。

10. Switch..case 語句，代碼塊需要留4個空格。

11. If語句嵌套，內部if語句需要留4個空格。

.h文件空行

以下情況要空行：

1. 頭文件包含(#import)與@class之間

2. @interface與@class之間

3. 頭文件{}內，空1行開始寫成員對象。

4. 頭文件{}外，空1行開始寫屬性。

5. 屬性與方法之間。

6. 如果需要聲明protocol，空2行接著寫。通常protocol寫在@end后面，但是聲明在@interface之前。

7. 方法與方法之間空1行。

8. 方法與@end之間。

.m文件空行

1. 文件說明與頭文件包含(#import)之間。

2. 頭文件包含(#import)之間。

3. @implementation和@synthesize之間。

4. @synthesize與方法之間。

5. 變量聲明后需要空1行。

6. 各功能塊之間。

7. #pragma mark 與方法之間。

Log

規則：統一使用自定的log服務，不直接使用系統自帶。

語句

每行只能有一個語句

每行代碼最多不得操作100個字符。

控制語句

If語句

判斷中如果有常量，則應將常量放在判斷式的右側，如if (a > b)

如：if (index > 0) …… //單條語句,放在if同一行

if (index > 0){ //多行語句

……….

}

While語句

循環語句中不允許出現表達式。

如while（I < documents.getCount()）

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

注釋

頭文件注釋：

所有的源文件都應該在開頭有一個注釋，其中列出頭文件的相關描述、作者、以及對應的版本信息。

/*!

@header 頭文件名稱

@abstract 關于這個源代碼文件的一些基本描述

@author作者

@version 1.00 2012/01/20 Creation (此文檔的版本信息：版本號+創建時間)

*/

類注釋

每一個類都要包含如下格式的注釋，以說明當前類的功能等。

/*!

@class類名

@abstract 這里可以寫關于這個類的一些描述。

*/

枚舉注釋

每一個枚舉都需要包含相對應的enum描述，以及每個枚舉值對應的含義。

/*!

@enum枚舉名稱

@abstract 關于這個enum的一些基本信息

@constant 各個對應值得含義，如： OKButton 對應的是OK按鈕的Tag

*/

typedef NS_ENUM (NSInteger,RunGoalTypeE){

kRunGoalTypeNone= 0,//無目標

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

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

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

};

協議注釋

協議需要注明是哪個類對應的protocol，以及自身的相關描述。

/*!

@protocol 協議名稱

@abstract 這是哪個類的protocol

@discussion 具體描述信息

*/

方法注釋

包括當前方法的用途，當前方法參數的含義，當前方法返回值的內容和對應的錯誤參照。

/*!

@method 方法名

@abstract該方法的一些簡要描述

@discussion該方法的具體使用方式，需要注意的地方，如果你是設計一個抽象類或者一個共通類給給其他類繼承的話，在這里需要具體描述一下怎樣使用這個方法。

@param text參數列表

@param error 錯誤參照

@result 返回結果

*/

屬性注釋

/*!

@property 屬性名稱

@abstract 該Property的一些基本描述。

*/

類別注釋

/*!

@category 類別名稱

@abstract 哪個類的類別

*/

文件組織結構

1. 類文件組織

建議邏輯結構和物理結構保持一致，以便有效地管理文件

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

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

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

2. 圖片資源文件組織

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

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

2. 類代碼組織

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

修改規范

新增代碼行

新增代碼行的前后應有注釋行說明。

//修改人，修改時間，修改說明

新增代碼行

//修改結束

刪除代碼行

刪除代碼向的前后用注釋行說明

//修改人，修改時間，修改說明

要刪除的代碼行(將要刪除的語句進行注釋)

//修改結束

修改代碼行

修改代碼行以注釋舊代碼行后再新增代碼行的方式進行。

//修改人，修改時間，修改說明

//修改前代碼行開始

//修改前代碼行

//修改前代碼行結束

//修改后代碼行開始

修改后代碼行

//修改結束

避免出現的情況

永遠不要有空的catch語句。替代方案：向方法的調用者拋出異常、或者抽象級別拋出新異常。

避免在一條語句中給多個變量賦相同的值

不要將賦值運算符用在與相等運算符混淆的地方

重復代碼，復制-粘貼

長方法，將所有邏輯處理放在一個方法里面，每個方法都應有其自己的意圖

大類，妄想將所有模塊放在一個類中實現。

小類，一個類所承擔的責任太少，應該將其消除，類的維護需要額外的開銷