命名規範

命名原則

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)程序中出現加密/解密 邏輯的操做地方,須要給出註釋說明過程(不管是系統仍是自定義)app

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



文/MichaelHuyp(簡書做者) 原文連接:http://www.jianshu.com/p/f5a3c3acef31 著做權歸做者全部,轉載請聯繫做者得到受權,並標註「簡書做者」。
相關文章
相關標籤/搜索