頭文件#import的順序(商量)
寫法模板
#import <系統庫>
#import <第三方庫>
#import “其他類”
儘量按照先系統類 第三方類 自己寫的類順序導入 中間不能有空格
建議的寫法
不建議的寫法
@Class的寫法
寫法模板：@class class1, class2;
建議的寫法
不建議的寫法
@Interface的寫法
寫法模板
@interface 類名 : 父類 <協議1, 2="">
@interface和類名中間一個空格
類名後緊跟:之後空格加上父類協議之間用,空格分割
建議的寫法
不建議的寫法
@protocol的寫法
寫法的模板
@protocol 協議的名稱 <協議1, 2="">
@potocol和協議的名稱有空格 協議的名稱和其他協議有空格 其他協議之間有空格
建議的寫法
不建議的寫法
@property的寫法
@property (關鍵詞, 關鍵詞) 類 *變量名稱;
關鍵詞用,空格分割 類前後空格
正確寫法
不建議的寫法
@property關鍵詞的使用
對象 strong
基本變量assign
XIB控件 代理 weak
字符串和block使用 copy
對於一些弱引用對象使用weak
對於需要賦值內存對象 copy
h頭文件方法寫法
寫法模板
@interface
方法的參數在一排顯示
方法之間保留一行
第一個方法和@interface保留空行
最後一個方法和@end保留空行
建議的寫法
錯誤寫法
聲明const的字符串
開頭用k標識
推薦k+模板名字首字母大寫+作用名稱 防止和其他的重複
比如:CartViewModel類需要聲明更新購物車列表的通知
kCVMNoticationUpdateCartList
如果是聲明Cell的重用字符
k+cell的名稱+identifier
比如: GBHomeItemTableViewCell的標識符
kGBHomeItemTableViewCellIdentifier
Const聲明字符串位置
如果是需要聲明在h裏面讓其他的類用到需要在h聲明m實現
聲明
實現
對於如果導入是UIKit類就使用UIKIT_EXTERN 如果是Founction使用關鍵詞FOUNDATION_EXTERN
如果只在本類使用只用寫實現 不用寫聲明。
方法儘量控制最多五十行
一個方法內部最多五十行 如果超過就精簡代碼 就分開方法寫
方便之後進行熱修復 代碼重構
註釋一定要寫
自己管理的類一定註釋屬性用途 方法的用途 參數的說明
屬性如果設置默認值 一定註明默認值是什麼
如果方法內部存在邏輯判斷 方法跳轉 一定註釋判斷用法 方法跳轉用法
除了初始化操作
其他聲明變量 賦值 判斷 應該註明註釋用途
註釋的寫法
Class類註釋
property屬性的註釋
方法的註釋
如果有返回值 請加上return
局部變量和全局變量註釋
Block註釋
NSUM的註釋
不允許外接修改的屬性要設置readonly
大家平時設置屬性默認是可讀可寫 但是這樣容易對於別人造成誤解 以爲可以賦值
對於只能獲取的屬性 一定寫readonly
正確的寫法
錯誤的寫法
頭文件引入的其他類 要使用@class
頭文件引入的類使用@class聲明不實用#import引入
可以防止互相引入 編譯失敗 不容易查找的BUG
造成的缺點
m文件還要#import 其他類調用這個類屬性也要#import對應的類
綜合來說寧願自己多操作 也要防止這種循環引入的BUG的出現
建議的寫法
不建議寫法
pragma mark的使用
對於屬性的不同作用 比如設置顏色的 設置字體的 設置其他樣式 的可以進行分組
對於方法的作用分類 比如添加功能 刪除功能的
對於其他的代理方法 Get Set方法 Init初始化方法
建議的寫法
BOOL類型屬性的聲明
屬性set不要帶is get要帶is
建議寫法
不建議寫法
方法命名的規範
不能用init set 開頭進行命名
如果不是寫初始化方法不要用init進行開頭
如果不是屬性的set方法不要用set作爲方法的前綴
{}的寫法
建議的寫法
不建議的寫法
計算符號兩邊要有空格
比如 + - * / =等運算符左右有空格
建議的寫法
不建議的寫法
控件命名的規範
對於命名一定不要簡寫 那篇很長的單詞 但是一些單詞就是簡寫的除外 比如WTO RMB
UILabel結尾加上Label;
UIImageView結尾記上ImageView
等等讓其他的編程人員看名字就知道變量的用法 和屬於什麼控件
建議的寫法
不建議的寫法
if判斷裏面的條件要提取出來
對於if裏面很多的判斷條件 要提取出來 方便之後進行斷點測試
建議的寫法
不建議的寫法
enum的定義
對於歸屬所在的enum 要寫在對應的類
我們現在就全部enum放在一個文件 覺得和蘋果的編碼規範違背 並且分離代碼有點麻煩
使用NS_ENUM進行定義
建議的寫法
不建議的寫法
對於初始化一定要使用類對應的初始化方法
比如UIView的對應初始化方法爲
UIViewController對應的爲
防止初始化用init new等沒經過系統進行設置一些默認的屬性 造成bug
對於聲明NSString const要對適應對應的模塊
比如系統的 NSNotificationName
建議的寫法
不建議的寫法
對於#define宏命名
單詞全部的大寫 單詞之間用_分割
建議的寫法
不建議的寫法
對象調用方法要留空格
建議的寫法
不建議的寫法
對於只在m內部聲明的const 需要添加static
這個我覺得可以不加 但是無法看到蘋果的實現 所以不知道蘋果的規範怎麼寫的
建議寫法
不建議的寫法
對於局部的變量儘量的初始化
局部的變量要初始化 屬性有默認的值 所以我們不必須對於屬性進行初始化
我之前遇到的一個BUG就是int類型沒有初始化給我默認Nan造成崩潰
建議的寫法
不建議的寫法
對於一些對象判斷是否賦值可以不進行初始化 但是對於一定不會爲nil要進行初始化
變量名的規範
一定要使用駝峯的命名
建議的寫法
不建議的寫法
對於屬性的賦值
不要直接調用set方法
建議的寫法
不建議的寫法
對於NS_OPTIONS類型多個值用|連接不能用+
建議的寫法
不建議的寫法
block的命名規範
之前研究過很多的第三方的命名 對於蘋果官方的沒找到
有CallBack結尾 Complete結尾 Block結尾 還有CompletionHandle結尾的
我看到蘋果很多的結尾都是用CompletionHandle結尾
大部分命名是Block我們按照Block命名
建議的寫法
錯誤寫法
使用NSUserDefaults要先創建
因爲我們用到NSUserDefaults無非是保存和讀取 事先的創建一個對象 可以精簡代碼
當執行方法很多 用變量替換
建議的寫法
不建議的寫法
儘量少在initialize load方法做一些初始化的事情
影響程序的啓動
建議的做法
不建議的做法
通知的移除
通知在dealloc要使用移除對象監聽的方法
建議的寫法
不建議的寫法
判斷不要放在一行
判斷放在一行也是可以的 但是我們還是要求正規一些 畢竟註明Apple的goto BUG
建議的寫法
不建議的寫法
對於我們取值和存值的key要定義一下
定義一下key 方便我們使用 並且方便之後改名字
建議的寫法
不建議的寫法
方法的參數連接不能有空格
建議的寫法
不建議的寫法
對於block的循環引用使用weakify 和strongify
建議的寫法
不建議的寫法
佈局和設置約束的方法選擇
可以實現GBInitViewProtocol協議 執行對應的方法
建議的寫法
有利於其他人很方便查找當前界面佈局和添加試圖的位置
屬性要儘量使用懶加載
我們一個界面有很多控件 利用懶加載可以美化代碼
所有的懶加載放在Getter的mark的下面
建議的寫法
推薦的界面框架
所有界面的控件元素獨立到另外的UIView
UIViewController只負責跳轉界面
新建UIView負責界面的顯示
VIewModel負責數據的請求和解析
APi負責請求
model負責後臺數據解析
other 負責樣式和其他處理
多使用字面量
字符串 @””
NSNumber @()
字典 @{}
數組 @[]
字典和數組的取值和存值
多用類型常量 少用#define
建議的寫法
不建議的寫法
對於一些狀態 選項的使用枚舉
儘量少用根據數字判斷狀態少用字符串 數字判斷狀態
建議的寫法
不建議的寫法
多使用類族
比如我們需要創建一個類 有多個樣式
ZHCustomRedView
ZHCustomWhiteView
類名加上前綴避免衝突
因爲團隊的合作 可能會出現大家想到一樣的名字或者添加第三方庫引入和第三方庫名字一樣
儘量加上前綴。
如果只針對工程就使用工程的縮寫
比如自己個人的第三方庫就加上自己名字或者暱稱的縮寫
建議的寫法
不建議的寫法
提供全能的初始化方法
對於初始化參數有很多 但是不是一定全部使用的可以提供多個初始化方法
建議的寫法
不建議的寫法
實現Description方便調試
這個不推薦自己手寫 可以使用Xcode插件自動生成 屬性越多會加重手寫代碼的長度
儘可能使用不可變的對象
對於OC存在很多可變的對象 比如NSMutableString NSMutableArray NSMutableDictionary等等
對於一些不允許改變的直接使用不可變對象
可以節省對象開支 還可以防止別人修改數據造成bug
建議的寫法
不建議的寫法
如果建議的使用Block和代理
我覺得代理可以用在寫控件需要數據源賦值 和一些事件回調的時候使用
我查閱了蘋果的block基本上都是執行一個時間 需要異步回調就使用block
如果沒有主動執行動作 而是監聽異步的回調 建議用代理
建議的寫法
不建議的寫法
記得Dealloc記得釋放
記得在Dealloc釋放註冊的通知和KVO的監聽
不釋放容易造成內存釋放崩潰
養成習慣把按照方法功能到分類裏面
對於一些有按照功能類型的方法劃分在一個分類裏面 分類和之前類寫在同一個文件
建議的寫法
不建議的寫法
爲第三方類添加分類添加前綴
比如爲系統UIView添加分類Add的添加前綴
建議的寫法
不建議的寫法
儘量少在分類裏面使用屬性
假設我們分類有一個只讀的字段 我們可以不使用屬性 可以使用方法
建議的寫法
不建議的寫法
非要在自己類的分類添加讀寫的屬性 可以用語法糖
可以利用主類的私有變量
建議的寫法
不建議的寫法
對於給第三方和系統的類非要添加屬性 可以使用runtime。
對於一些自己不確定的可以使用try catch
對於不知道後臺返回什麼類型的 可以使用try catch
建議的寫法
因爲OC是運行時語法 可能array不一定是NSArray類型的
不建議的寫法
如果後臺返回list爲字段 這段代碼就崩潰了 可以使用try catch也可以用Model庫 或者自己添加判斷
使用dispatch_once來創建單例
建議的寫法
不建議的寫法
便利的寫法
如果只需要便利數組和字典的寫法用for in
建議的寫法
不建議的寫法
需要便利字典和數組的內容 並且需要索引用enumerator
建議的寫法
不建議的寫法
如果想進行緩存使用NSCache不要使用NSDictionary進行緩存
建議的寫法
不建議的寫法
尤達表達式
推薦:
不推薦:
nil 和 BOOL 檢查
推薦
不建議的寫法
黃金大道
建議的寫法
不建議的寫法
複雜的表達式
建議的寫法
不建議的寫法
三元運算符
推薦:
不推薦:
當三元運算符的第二個參數（if 分支）返回和條件語句中已經檢查的對象一樣的對象的時候，下面的表達方式更靈巧：
推薦:
不推薦:
錯誤處理
有些方法通通過參數返回 error 的引用，使用這樣的方法時應當檢查方法的返回值，而非 error 的引用。
推薦:
此外，一些蘋果的 API 在成功的情況下會對 error 參數（如果它非 NULL）寫入垃圾值（garbage values），所以如果檢查 error 的值可能導致錯誤 （甚至崩潰）。
數組和字典最好指定元素的類型
建議的寫法
不建議的寫法
數組和字典的元素垂直寫
建議的寫法
不建議寫法
