Objective-C開發編碼規範

Objective-C編碼規範，內容來自蘋果、谷歌的文件翻譯，自己的編碼經驗和對其它資料的總結。

轉載請註明出處。

概要

Objective-C是一門物件導向的動態程式語言，主要用於編寫iOS和Mac應用程式。關於Objective-C的編碼規範，蘋果和谷歌都已經有很好的總結：

• Apple Coding Guidelines for Cocoa
• Google Objective-C Style Guide

本文主要整合了對上述文件的翻譯、作者自己的程式設計經驗和其他的相關資料，為公司總結出一份通用的編碼規範。

程式碼格式

使用空格而不是製表符Tab

不要在工程裡使用Tab鍵，使用空格來進行縮排。在Xcode > Preferences > Text Editing將Tab和自動縮排都設定為4個空格。（Google的標準是使用兩個空格來縮排，但這裡還是推薦使用Xcode預設的設定。）

每一行的最大長度

同樣的，在Xcode > Preferences > Text Editing > Page guide at column:中將最大行長設定為80，過長的一行程式碼將會導致可讀性問題。

函式的書寫

一個典型的Objective-C函式應該是這樣的：

在-和(void)之間應該有一個空格，第一個大括號{的位置在函式所在行的末尾，同樣應該有一個空格。（我司的C語言規範要求是第一個大括號單獨佔一行，但考慮到OC較長的函式名和蘋果SDK程式碼的風格，還是將大括號放在行末。）

如果一個函式有特別多的引數或者名稱很長，應該將其按照:來對齊分行顯示：

在分行時，如果第一段名稱過短，後續名稱可以以Tab的長度（4個空格）為單位進行縮排：

函式呼叫

函式呼叫的格式和書寫差不多，可以按照函式的長短來選擇寫在一行或者分成多行：

以下寫法是錯誤的：

@public和@private標記符

@public和@private標記符應該以一個空格來進行縮排：

協議（Protocols）

在書寫協議的時候注意用<>括起來的協議和型別名之間是沒有空格的，比如IPCConnectHandler()<IPCPreconnectorDelegate>,這個規則適用所有書寫協議的地方，包括函式宣告、類宣告、例項變數等等：

閉包（Blocks）

根據block的長度，有不同的書寫規則：

• 較短的block可以寫在一行內。
• 如果分行顯示的話，block的右括號}應該和呼叫block那行程式碼的第一個非空字元對齊。
• block內的程式碼採用4個空格的縮排。
• 如果block過於龐大，應該單獨宣告成一個變數來使用。
• ^和(之間，^和{之間都沒有空格，引數列表的右括號)和{之間有一個空格。

資料結構的語法糖

應該使用可讀性更好的語法糖來構造NSArray，NSDictionary等資料結構，避免使用冗長的alloc,init方法。

如果構造程式碼寫在一行，需要在括號兩端留有一個空格，使得被構造的元素於與構造語法區分開來：

如果構造程式碼不寫在一行內，構造元素需要使用兩個空格來進行縮排，右括號]或者}寫在新的一行，並且與呼叫語法糖那行程式碼的第一個非空字元對齊：

構造字典時，字典的Key和Value與中間的冒號:都要留有一個空格，多行書寫時，也可以將Value對齊：

命名規範

基本原則

清晰

命名應該儘可能的清晰和簡潔，但在Objective-C中，清晰比簡潔更重要。由於Xcode強大的自動補全功能，我們不必擔心名稱過長的問題。

不要使用單詞的簡寫，拼寫出完整的單詞：

然而，有部分單詞簡寫在Objective-C編碼過程中是非常常用的，以至於成為了一種規範，這些簡寫可以在程式碼中直接使用，下面列舉了部分：

命名方法或者函式時要避免歧義

一致性

整個工程的命名風格要保持一致性，最好和蘋果SDK的程式碼保持統一。不同類中完成相似功能的方法應該叫一樣的名字，比如我們總是用count來返回集合的個數，不能在A類中使用count而在B類中使用getNumber。

使用字首

如果程式碼需要打包成Framework給別的工程使用，或者工程專案非常龐大，需要拆分成不同的模組，使用命名字首是非常有用的。

• 字首由大寫的字母縮寫組成，比如Cocoa中NS字首代表Founation框架中的類，IB則代表Interface Builder框架。
• 可以在為類、協議、函式、常量以及typedef巨集命名的時候使用字首，但注意不要為成員變數或者方法使用字首，因為他們本身就包含在類的名稱空間內。
• 命名字首的時候不要和蘋果SDK框架衝突。

命名類和協議（Class&Protocol）

類名以大寫字母開頭，應該包含一個名詞來表示它代表的物件型別，同時可以加上必要的字首，比如NSString, NSDate, NSScanner, NSApplication等等。

而協議名稱應該清晰地表示它所執行的行為，而且要和類名區別開來，所以通常使用ing詞尾來命名一個協議，比如NSCopying,NSLocking。

有些協議本身包含了很多不相關的功能，主要用來為某一特定類服務，這時候可以直接用類名來命名這個協議，比如NSObject協議，它包含了id物件在生存週期內的一系列方法。

命名標頭檔案（Headers）

原始碼的標頭檔案名應該清晰地暗示它的功能和包含的內容：

• 如果標頭檔案內只定義了單個類或者協議，直接用類名或者協議名來命名標頭檔案，比如NSLocale.h定義了NSLocale類。
• 如果標頭檔案內定義了一系列的類、協議、類別，使用其中最主要的類名來命名標頭檔案，比如NSString.h定義了NSString和NSMutableString。
• 每一個Framework都應該有一個和框架同名的標頭檔案，包含了框架中所有公共類標頭檔案的引用，比如Foundation.h
• Framework中有時候會實現在別的框架中類的類別擴充套件，這樣的檔案通常使用被擴充套件的框架名+Additions的方式來命名，比如NSBundleAdditions.h。

命名方法（Methods）

Objective-C的方法名通常都比較長，這是為了讓程式有更好地可讀性，按蘋果的說法“好的方法名應當可以以一個句子的形式朗讀出來”。

方法一般以小寫字母打頭，每一個後續的單詞首字母大寫，方法名中不應該有標點符號（包括下劃線），有兩個例外：

• 可以用一些通用的大寫字母縮寫打頭方法，比如PDF,TIFF等。
• 可以用帶下劃線的字首來命名私有方法或者類別中的方法。

如果方法表示讓物件執行一個動作，使用動詞打頭來命名，注意不要使用do，does這種多餘的關鍵字，動詞本身的暗示就足夠了：

如果方法是為了獲取物件的一個屬性值，直接用屬性名稱來命名這個方法，注意不要新增get或者其他的動詞字首：

對於有多個引數的方法，務必在每一個引數前都新增關鍵詞，關鍵詞應當清晰說明引數的作用：

不要用and來連線兩個引數，通常and用來表示方法執行了兩個相對獨立的操作（從設計上來說，這時候應該拆分成兩個獨立的方法）：

方法的引數命名也有一些需要注意的地方:

• 和方法名類似，引數的第一個字母小寫，後面的每一個單詞首字母大寫
• 不要再方法名中使用類似pointer,ptr這樣的字眼去表示指標，引數本身的型別足以說明
• 不要使用只有一兩個字母的引數名
• 不要使用簡寫，拼出完整的單詞

下面列舉了一些常用引數名：

存取方法（Accessor Methods）

存取方法是指用來獲取和設定類屬性值的方法，屬性的不同型別，對應著不同的存取方法規範：

命名存取方法時不要將動詞轉化為被動形式來使用：

可以使用can,should,will等詞來協助表達存取方法的意思，但不要使用do,和does：

為什麼Objective-C中不適用get字首來表示屬性獲取方法？因為get在Objective-C中通常只用來表示從函式指標返回值的函式：

命名委託（Delegate）

當特定的事件發生時，物件會觸發它註冊的委託方法。委託是Objective-C中常用的傳遞訊息的方式。委託有它固定的命名正規化。

一個委託方法的第一個引數是觸發它的物件，第一個關鍵詞是觸發物件的類名，除非委託方法只有一個名為sender的引數：

根據委託方法觸發的時機和目的，使用should,will,did等關鍵詞

集合操作類方法（Collection Methods）

有些物件管理著一系列其它物件或者元素的集合，需要使用類似“增刪查改”的方法來對集合進行操作，這些方法的命名正規化一般為：

注意，如果返回的集合是無序的，使用NSSet來代替NSArray。如果需要將元素插入到特定的位置，使用類似於這樣的命名：

如果管理的集合元素中有指向管理物件的指標，要設定成weak型別以防止引用迴圈。

下面是SDK中NSWindow類的集合操作方法：

命名函式（Functions）

在很多場合仍然需要用到函式，比如說如果一個物件是一個單例，那麼應該使用函式來代替類方法執行相關操作。

函式的命名和方法有一些不同，主要是：

• 函式名稱一般帶有縮寫字首，表示方法所在的框架。
• 字首後的單詞以“駝峰”表示法顯示，第一個單詞首字母大寫。

函式名的第一個單詞通常是一個動詞，表示方法執行的操作：

如果函式返回其引數的某個屬性，省略動詞：

如果函式通過指標引數來返回值，需要在函式名中使用Get：

函式的返回型別是BOOL時的命名：

命名屬性和例項變數（Properties&Instance Variables）

屬性和物件的存取方法相關聯，屬性的第一個字母小寫，後續單詞首字母大寫，不必新增字首。屬性按功能命名成名詞或者動詞：

屬性也可以命名成形容詞，這時候通常會指定一個帶有is字首的get方法來提高可讀性：

命名例項變數，在變數名前加上_字首（有些有歷史的程式碼會將_放在後面），其它和命名屬性一樣：

一般來說，類需要對使用者隱藏資料儲存的細節，所以不要將例項方法定義成公共可訪問的介面，可以使用@private，@protected字首。

按蘋果的說法，不建議在除了init和dealloc方法以外的地方直接訪問例項變數，但很多人認為直接訪問會讓程式碼更加清晰可讀，只在需要計算或者執行操作的時候才使用存取方法訪問，我就是這種習慣，所以這裡不作要求。

命名常量（Constants）

如果要定義一組相關的常量，儘量使用列舉型別（enumerations），列舉型別的命名規則和函式的命名規則相同。 建議使用 NS_ENUM 和 NS_OPTIONS 巨集來定義列舉型別，參見官方的 Adopting Modern Objective-C 一文：

定義bit map：

使用const定義浮點型或者單個的整數型常量，如果要定義一組相關的整數常量，應該優先使用列舉。常量的命名規範和函式相同：

不要使用#define巨集來定義常量，如果是整型常量，儘量使用列舉，浮點型常量，使用const定義。#define通常用來給編譯器決定是否編譯某塊程式碼，比如常用的：

注意到一般由編譯器定義的巨集會在前後都有一個__，比如__MACH__。

命名通知（Notifications）

通知常用於在模組間傳遞訊息，所以通知要儘可能地表示出發生的事件，通知的命名正規化是：

栗子：

註釋

讀沒有註釋程式碼的痛苦你我都體會過，好的註釋不僅能讓人輕鬆讀懂你的程式，還能提升程式碼的逼格。注意註釋是為了讓別人看懂，而不是僅僅你自己。

檔案註釋

每一個檔案都必須寫檔案註釋，檔案註釋通常包含

• 檔案所在模組
• 作者資訊
• 歷史版本資訊
• 版權資訊
• 檔案包含的內容，作用

一段良好檔案註釋的栗子：

檔案註釋的格式通常不作要求，能清晰易讀就可以了，但在整個工程中風格要統一。

程式碼註釋

好的程式碼應該是“自解釋”（self-documenting）的，但仍然需要詳細的註釋來說明引數的意義、返回值、功能以及可能的副作用。

方法、函式、類、協議、類別的定義都需要註釋，推薦採用Apple的標準註釋風格，好處是可以在引用的地方alt+點選自動彈出註釋，非常方便。

有很多可以自動生成註釋格式的外掛，推薦使用VVDocumenter：

一些良好的註釋：

協議、委託的註釋要明確說明其被觸發的條件：

如果在註釋中要引用引數名或者方法函式名，使用||將引數或者方法括起來以避免歧義：

定義在標頭檔案裡的介面方法、屬性必須要有註釋！

編碼風格

每個人都有自己的編碼風格，這裡總結了一些比較好的Cocoa程式設計風格和注意點。

不要使用new方法

儘管很多時候能用new代替alloc init方法，但這可能會導致除錯記憶體時出現不可預料的問題。Cocoa的規範就是使用alloc init方法，使用new會讓一些讀者困惑。

Public API要儘量簡潔

共有介面要設計的簡潔，滿足核心的功能需求就可以了。不要設計很少會被用到，但是引數極其複雜的API。如果要定義複雜的方法，使用類別或者類擴充套件。

#import和#include

#import是Cocoa中常用的引用標頭檔案的方式，它能自動防止重複引用檔案，什麼時候使用#import，什麼時候使用#include呢？

• 當引用的是一個Objective-C或者Objective-C++的標頭檔案時，使用#import
• 當引用的是一個C或者C++的標頭檔案時，使用#include，這時必須要保證被引用的檔案提供了保護域（#define guard）。

栗子：

為什麼不全部使用#import呢？主要是為了保證程式碼在不同平臺間共享時不出現問題。

引用框架的根標頭檔案

上面提到過，每一個框架都會有一個和框架同名的標頭檔案，它包含了框架內介面的所有引用，在使用框架的時候，應該直接引用這個根標頭檔案，而不是其它子模組的標頭檔案，即使是你只用到了其中的一小部分，編譯器會自動完成優化的。

BOOL的使用

BOOL在Objective-C中被定義為signed char型別，這意味著一個BOOL型別的變數不僅僅可以表示YES(1)和NO(0)兩個值，所以永遠不要將BOOL型別變數直接和YES比較：

同樣的，也不要將其它型別的值作為BOOL來返回，這種情況下，BOOL變數只會取值的最後一個位元組來賦值，這樣很可能會取到0（NO）。但是，一些邏輯操作符比如&&,||,!的返回是可以直接賦給BOOL的：

另外BOOL型別可以和_Bool,bool相互轉化，但是不能和Boolean轉化。

使用ARC

除非想要相容一些古董級的機器和作業系統，我們沒有理由放棄使用ARC。在最新版的Xcode(6.2)中，ARC是自動開啟的，所以直接使用就好了。

在init和dealloc中不要用存取方法訪問例項變數

當initdealloc方法被執行時，類的執行時環境不是處於正常狀態的，使用存取方法訪問變數可能會導致不可預料的結果，因此應當在這兩個方法內直接訪問例項變數。

按照定義的順序釋放資源

在類或者Controller的生命週期結束時，往往需要做一些掃尾工作，比如釋放資源，停止執行緒等，這些掃尾工作的釋放順序應當與它們的初始化或者定義的順序保持一致。這樣做是為了方便除錯時尋找錯誤，也能防止遺漏。

保證NSString在賦值時被複制

NSString非常常用，在它被傳遞或者賦值時應當保證是以複製（copy）的方式進行的，這樣可以防止在不知情的情況下String的值被其它物件修改。

使用NSNumber的語法糖

使用帶有@符號的語法糖來生成NSNumber物件能使程式碼更簡潔：

nil檢查

因為在Objective-C中向nil物件傳送命令是不會丟擲異常或者導致崩潰的，只是完全的“什麼都不幹”，所以，只在程式中使用nil來做邏輯上的檢查。

另外，不要使用諸如nil == Object或者Object == nil的形式來判斷。

屬性的執行緒安全

定義一個屬性時，編譯器會自動生成執行緒安全的存取方法（Atomic），但這樣會大大降低效能，特別是對於那些需要頻繁存取的屬性來說，是極大的浪費。所以如果定義的屬性不需要執行緒保護，記得手動新增屬性關鍵字nonatomic來取消編譯器的優化。

點分語法的使用

不要用點分語法來呼叫方法，只用來訪問屬性。這樣是為了防止程式碼可讀性問題。

Delegate要使用弱引用

一個類的Delegate物件通常還引用著類本身，這樣很容易造成引用迴圈的問題，所以類的Delegate屬性要設定為弱引用。