首頁»移動開發»Objective-C編碼規范:26個方面解決iOS開發問題

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

來源:csdn 發布時間:2015-07-04 閱讀次數:

  【按語】由于我正在準備模擬開發餓了么這個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 AzarpourRicardo Rendon CepedaTony DahburaColin EberhardtMatt GallowayGreg HeoMatthijs HollemansChristopher LaPolloSaul MoraAndy PereiraMic PringlePietro ReaCesare RocchiMarin TodorovNicholas WaynikRay 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;
QQ群:WEB開發者官方群(515171538),驗證消息:10000
微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
網友評論(共0條評論) 正在載入評論......
理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
登錄會員中心
湖北快3今天的开奖结果