Objective-C編碼規範：26個方面解決iOS開發問題

csdn發表於2015-07-04
ObjectiOS

　　【按語】由於我正在準備模擬開發餓了麼這個App，到時可能有些iOS開發者參與進來。這時如果每個人的Objective-C編碼風格都不一樣，這樣不易於保持程式碼一致性和難以Code Review。所以我在網上搜尋到The official raywenderlich.com Objective-C style guide這篇關於Objective-C編碼風格的文章，覺得可以作為這個專案的Objective-C的編碼標準，所以就翻譯這篇文章。這篇編碼風格指南概括了raywenderlich.com的編碼規範，可能有些刪減或修改。

　　介紹

　　我們制定Objective-C編碼規範的原因是我們能夠在我們的書，教程和初學者工具包的程式碼保持優雅和一致。即使我們有很多不同的作者來完成不同的書籍。

　　這裡編碼規範有可能與你看到的其他Objective-C編碼規範不同，因為它主要是為了列印和Web的易讀性。

　　關於作者

　　這編碼規範的建立是由很多來自raywenderlich.com團隊成員在Nicholas Waynik的帶領下共同完成的。團隊成員有：Soheil Moayedi Azarpour、Ricardo Rendon Cepeda、Tony Dahbura、Colin Eberhardt、Matt Galloway、Greg Heo、Matthijs Hollemans、Christopher LaPollo、Saul Mora、Andy Pereira、Mic Pringle、Pietro Rea、Cesare Rocchi、Marin Todorov、Nicholas Waynik和Ray Wenderlich。

　　我們也非常感謝New York Times 和Robots & Pencils'Objective-C編碼規範的作者。這兩個編碼規範為本指南的建立提供很好的起點。

　　背景

　　這裡有些關於編碼風格Apple官方文件，如果有些東西沒有提及，可以在以下文件來查詢更多細節：

　　語言

　　應該使用US英語。

　　應該：

UIColor *myColor = [UIColor whiteColor];

　　不應該：

UIColor *myColour = [UIColor whiteColor];

　　程式碼組織

　　在函式分組和protocol/delegate實現中使用#pragma mark -來分類方法，要遵循以下一般結構：

#pragma mark - Lifecycle
- (instancetype)init {}
- (void)dealloc {}
- (void)viewDidLoad {}
- (void)viewWillAppear:(BOOL)animated {}
- (void)didReceiveMemoryWarning {}
#pragma mark - Custom Accessors
- (void)setCustomProperty:(id)value {}
- (id)customProperty {}
#pragma mark - IBActions
- (IBAction)submitData:(id)sender {}
#pragma mark - Public
- (void)publicMethod {}
#pragma mark - Private
- (void)privateMethod {}
#pragma mark - Protocol conformance
#pragma mark - UITextFieldDelegate
#pragma mark - UITableViewDataSource
#pragma mark - UITableViewDelegate
#pragma mark - NSCopying
- (id)copyWithZone:(NSZone *)zone {}
#pragma mark - NSObject
- (NSString *)description {}

　　空格

  • 縮排使用4個空格，確保在Xcode偏好設定來設定。（raywenderlich.com使用2個空格）
  • 方法大括號和其他大括號(if/else/switch/while 等.)總是在同一行語句開啟但在新行中關閉。

　　應該：

if (user.isHappy) {
    //Do something
} else {
    //Do something else
}

不應該：

if (user.isHappy)
{
  //Do something
}
else {
  //Do something else
}
  • 在方法之間應該有且只有一行，這樣有利於在視覺上更清晰和更易於組織。在方法內的空白應該分離功能，但通常都抽離出來成為一個新方法。
  • 優先使用auto-synthesis。但如果有必要，@synthesize和@dynamic應該在實現中每個都宣告新的一行。
  • 應該避免以冒號對齊的方式來呼叫方法。因為有時方法簽名可能有3個以上的冒號和冒號對齊會使程式碼更加易讀。請不要這樣做，儘管冒號對齊的方法包含程式碼塊，因為Xcode的對齊方式令它難以辨認。

　　應該：

// blocks are easily readable
[UIView animateWithDuration:1.0 animations:^{
  // something
} completion:^(BOOL finished) {
  // something
}];

　　不應該：

// colon-aligning makes the block indentation hard to read
[UIView animateWithDuration:1.0
                 animations:^{
                     // something
                 }
                 completion:^(BOOL finished) {
                     // something
                 }];

　　註釋

　　當需要註釋時，註釋應該用來解釋這段特殊程式碼為什麼要這樣做。任何被使用的註釋都必須保持最新或被刪除。

　　一般都避免使用塊註釋，因為程式碼儘可能做到自解釋，只有當斷斷續續或幾行程式碼時才需要註釋。例外：這不應用在生成文件的註釋

　　命名

　　Apple命名規則儘可能堅持，特別是與這些相關的memory management rules (NARC)。

　　長的，描述性的方法和變數命名是好的。

　　應該：

UIButton *settingsButton;

　　不應該：

UIButton *setBut;

　　三個字元字首應該經常用在類和常量命名，但在Core Data的實體名中應被忽略。對於官方的raywenderlich.com書、初學者工具包或教程，字首'RWT'應該被使用。

　　常量應該使用駝峰式命名規則，所有的單詞首字母大寫和加上與類名有關的字首。

　　應該：

static NSTimeInterval const RWTTutorialViewControllerNavigationFadeAnimationDuration = 0.3;

　　不應該：

static NSTimeInterval const fadetime = 1.7;

　　屬性也是使用駝峰式，但首單詞的首字母小寫。對屬性使用auto-synthesis，而不是手動編寫@synthesize語句，除非你有一個好的理由。

　　應該：

@property (strong, nonatomic) NSString *descriptiveVariableName;

　　不應該：

id varnm;

相關文章