原文

提升自己逼格的編程之美之代碼規范

頭文件#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 的值可能導致錯誤 （甚至崩潰）。

數組和字典最好指定元素的類型

建議的寫法

? ?

不建議的寫法

? ?

數組和字典的元素垂直寫

建議的寫法

? ?

不建議寫法