[Objective-C] 014_Objective-C 代碼規範指南(上)

標籤：

本文參考引用(http://www.csdn.net/article/2015-06-01/2824818-objective-c-style-guide/1)

擁有良好的編碼規範，能使我們的代碼保持優雅，易讀，易維護。我們現在從下面這些點開搞。

1.程式碼群組織

• 在函數分組和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 {}

2.空格

• 設定縮排使用4個空格，確保在Xcode喜好設定來。
• 方法大括弧和其他大括弧(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.注釋

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

4.命名

• Apple命名規則儘可能堅持，特別是與這些相關的memory management rules (NARC)。
• 長的，描述性的方法和變數命名是好的。 　　
  

　　應該：

UIButton *settingsButton;

　　不應該：

UIButton *setBut; 

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

　　應該：

static NSTimeInterval const RWTTutorialViewControllerNavigationFadeAnimationDuration = 0.3;

　　不應該：

static NSTimeInterval const fadetime = 1.7;

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

　　應該：

@property (strong, nonatomic) NSString *descriptiveVariableName;

　　不應該：

NSString *descriptiveVariableName;

5.底線

• 當使用屬性時，執行個體變數應該使用self.來訪問和改變。這就意味著所有屬性將會視覺效果不同，因為它們前面都有self.。
• 但有一個特例：在初始化方法裡，執行個體變數(例如，_variableName)應該直接被使用來避免getters/setters潛在的副作用。
• 局部變數不應該包含底線。

6.方法

• 在方法簽名中，應該在方法類型(-/+ 符號)之後有一個空格。在方法各個段之間應該也有一個空格(符合Apple的風格)。在參數之前應該包含一個具有描述性的關鍵字來描述參數。
• "and"這個詞的用法應該保留。它不應該用於多個參數來說明，就像initWithWidth:height以下這個例子：

　　應該：

- (void)setExampleText:(NSString *)text image:(UIImage *)image;- (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag;- (id)viewWithTag:(NSInteger)tag;- (instancetype)initWithWidth:(CGFloat)width height:(CGFloat)height;

　　不應該: 

-(void)setT:(NSString *)text i:(UIImage *)image;- (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag;- (id)taggedView:(NSInteger)tag;- (instancetype)initWithWidth:(CGFloat)width andHeight:(CGFloat)height;- (instancetype)initWith:(int)width and:(int)height;  // Never do this.

7.變數

• 變數盡量以描述性的方式來命名。單個字元的變數命名應該盡量避免，除了在for()迴圈。
• 星號表示變數是指標。例如， NSString *text 既不是 NSString* text 也不是 NSString * text，除了一些特殊情況下常量。
• 私人變數應該儘可能代替執行個體變數的使用。儘管使用執行個體變數是一種有效方式，但更偏向於使用屬性來保持代碼一致性。
• 通過使用‘back‘屬性(_variable，變數名前面有底線)直接存取執行個體變數應該盡量避免，除了在初始化方法(init, initWithCoder:, 等…)，dealloc 方法和自訂的setters和getters。想瞭解關於如何在初始化方法和dealloc直接使用Accessor方法的更多資訊，查看這裡。

 　應該：

@interface RWTTutorial : NSObject@property (strong, nonatomic) NSString *tutorialName;@end

　　不應該：

@interface RWTTutorial : NSObject {  NSString *tutorialName;}

8.屬性特性

• 所有屬性特性應該顯式地列出來，有助於新手閱讀代碼。屬性特性的順序應該是storage、atomicity，與在Interface Builder串連UI元素時自動產生代碼一致。

　　應該：

@property (weak, nonatomic) IBOutlet UIView *containerView;@property (strong, nonatomic) NSString *tutorialName;

　　不應該：

@property (nonatomic, weak) IBOutlet UIView *containerView;@property (nonatomic) NSString *tutorialName;

• NSString應該使用copy而不是strong的屬性特性。（為什嗎？即使你聲明一個NSString的屬性，有人可能傳入一個NSMutableString的執行個體，然後在你沒有注意的情況下修改它）

　　應該：

@property (copy, nonatomic) NSString *tutorialName;

　　不應該：

@property (strong, nonatomic) NSString *tutorialName;

9.點符號文法

• 點文法是一種很方便封裝存取方法調用的方式。當你使用點文法時，通過使用getter或setter方法，屬性仍然被訪問或修改。想瞭解更多，閱讀這裡。　
• 點文法應該總是被用來訪問和修改屬性，因為它使代碼更加簡潔。[]符號更偏向於用在其他例子。　

　　應該: 

NSInteger arrayCount = [self.array count];view.backgroundColor = [UIColor orangeColor];[UIApplication sharedApplication].delegate;

　　不應該：

NSInteger arrayCount = self.array.count;[view setBackgroundColor:[UIColor orangeColor]];UIApplication.sharedApplication.delegate;

10.字面值

• NSString、NSDictionary、NSArray和NSNumber的字面值應該在建立這些類的不可變執行個體時被使用。請特別注意nil值不能傳入NSArray和NSDictionary字面值，因為這樣會導致crash。

　　應該：

NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];  NSDictionary *productManagers = @{@"iPhone": @"Kate", @"iPad": @"Kamal", @"Mobile Web": @"Bill"};  NSNumber *shouldUseLiterals = @YES;  NSNumber *buildingStreetNumber = @10018;

　　不應該：

NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];  NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];  NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];  NSNumber *buildingStreetNumber = [NSNumber numberWithInteger:10018]; 

11.常量

• 常量是容易重複被使用和無需通過尋找和代替就能快速修改值。常量應該使用static來聲明而不是使用#define，除非顯式地使用宏。

　　應該：

static NSString * const RWTAboutViewControllerCompanyName = @"RayWenderlich.com";static CGFloat const RWTImageThumbnailHeight = 50.0;

　　不應該：

#define CompanyName @"RayWenderlich.com"#define thumbnailHeight 2

12.枚舉

• 當使用enum時，推薦使用新的固定基本類型規格，因為它有更強的類型檢查和代碼補全。現在SDK有一個宏NS_ENUM()來協助和鼓勵你使用固定的基本類型。

typedef NS_ENUM(NSInteger, RWTLeftMenuTopItemType) {  RWTLeftMenuTopItemMain,  RWTLeftMenuTopItemShows,  RWTLeftMenuTopItemSchedule};

　　顯式地賦值(展示舊的k-style常量定義)：

typedef NS_ENUM(NSInteger, RWTGlobalConstants) {  RWTPinSizeMin = 1,  RWTPinSizeMax = 5,  RWTPinCountMin = 100,  RWTPinCountMax = 500,};

13.case 語句

• 大括弧在case語句中並不是必須的，除非編譯器強制要求。當一個case語句包含多行代碼時，大括弧應該加上。

switch (condition) {  case 1:    // ...    break;  case 2: {    // ...    // Multi-line example using braces    break;  }  case 3:    // ...    break;  default:     // ...    break;}

• 有很多次，當相同代碼被多個cases使用時，一個fall-through應該被使用。一個fall-through就是在case最後移除‘break‘語句，這樣就能夠允許執行流程跳轉到下一個case值。為了代碼更加清晰，一個fall-through需要注釋一下。

switch (condition) {  case 1:    // ** fall-through! **  case 2:    // code executed for values 1 and 2    break;  default:     // ...    break;}

• 當在switch使用枚舉類型時，‘default‘是不需要的。例如：

RWTLeftMenuTopItemType menuType = RWTLeftMenuTopItemMain;switch (menuType) {  case RWTLeftMenuTopItemMain:    // ...    break;  case RWTLeftMenuTopItemShows:    // ...    break;  case RWTLeftMenuTopItemSchedule:    // ...    break;}

14.私人屬性

• 私人屬性應該在類的實現檔案中的類擴充(匿名分類)中聲明，命名分類(比如RWTPrivate或private)應該從不使用除非是擴充其他類。匿名分類應該通過使用<headerfile>+Private.h檔案的命名規則暴露給測試。

@interface RWTDetailViewController ()@property (strong, nonatomic) GADBannerView *googleAdView;@property (strong, nonatomic) ADBannerView *iAdView;@property (strong, nonatomic) UIWebView *adXWebView;@end

15.布爾值

• Objective-C使用YES和NO。因為true和false應該只在CoreFoundation，C或C++代碼使用。既然nil解析成NO，所以沒有必要在條件陳述式比較。不要拿某樣東西直接與YES比較，因為YES被定義為1和一個BOOL能被設定為8位。

  這是為了在不同檔案保持一致性和在視覺上更加簡潔而考慮。

　　應該:

if (someObject) {}  if (![anotherObject boolValue]) {} 

　　不應該：

if (someObject == nil) {}  if ([anotherObject boolValue] == NO) {}  if (isAwesome == YES) {} // Never do this.  if (isAwesome == true) {} // Never do this. 

• 如果BOOL屬性的名字是一個形容詞，屬性就能忽略"is"首碼，但要指定get訪問器的慣用名稱。例如：

@property (assign, getter=isEditable) BOOL editable;  

　　文字和例子從這裡引用Cocoa Naming Guidelines。

17.條件陳述式

• 條件陳述式主體為了防止出錯應該使用大括弧包圍，即使條件陳述式主體能夠不用大括弧編寫(如，只用一行代碼)。這些錯誤包括添加第二行代碼和期望它成為if語句；還有，even more dangerous defect可能發生在if語句裡面一行代碼被注釋了，然後下一行代碼不知不覺地成為if語句的一部分。除此之外，這種風格與其他條件陳述式的風格保持一致，所以更加容易閱讀。

　　應該：

if (!error) {    return success;  } 

　　不應該：

if (!error)    return success; 

　　或者：

if (!error) return success; 

18.三元操作符

• 當需要提高代碼的清晰性和簡潔性時，三元操作符?:才會使用。單個條件求值常常需要它。多個條件求值時，如果使用if語句或重構成執行個體變數時，代碼會更加易讀。一般來說，最好使用三元操作符是在根據條件來賦值的情況下。
• Non-boolean的變數與某東西比較，加上括弧()會提高可讀性。如果被比較的變數是boolean類型，那麼就不需要括弧。

　　應該：

NSInteger value = 5;  result = (value != 0) ? x : y;  BOOL isHorizontal = YES;  result = isHorizontal ? x : y; 

　　不應該：

result = a > b ? x = c > d ? c : d : y;

19.Init 方法

• Init方法應該遵循Apple產生代碼模板的命名規則，傳回型別應該使用instancetype而不是id。

- (instancetype)init {    self = [super init];    if (self) {      // ...    }    return self;  } 

20.構造方法

• 當類構造方法被使用時，它應該傳回型別是instancetype而不是id。這樣確保編譯器正確地推斷結果類型。

@interface Airplane  + (instancetype)airplaneWithType:(RWTAirplaneType)type;  @end 

　　關於更多instancetype資訊，請查看NSHipster.com。

21.CGRect函數

• 當訪問CGRect裡的x, y, width, 或 height時，應該使用CGGeometry函數而不是直接通過結構體來訪問。

　　應該：

CGRect frame = self.view.frame;  CGFloat x = CGRectGetMinX(frame);  CGFloat y = CGRectGetMinY(frame);  CGFloat width = CGRectGetWidth(frame);  CGFloat height = CGRectGetHeight(frame);  CGRect frame = CGRectMake(0.0, 0.0, width, height); 

　　不應該：

CGRect frame = self.view.frame;  CGFloat x = frame.origin.x;  CGFloat y = frame.origin.y;  CGFloat width = frame.size.width;  CGFloat height = frame.size.height;  CGRect frame = (CGRect){ .origin = CGPointZero, .size = frame.size };

22.黃金路徑

• 當使用條件陳述式編碼時，左手邊的代碼應該是"golden" 或 "happy"路徑。也就是不要嵌套if語句，多個返回語句也是OK。

　　應該：

- (void)someMethod {    if (![someOther boolValue]) {      return;    }    //Do something important  } 

　　不應該：

- (void)someMethod {    if ([someOther boolValue]) {      //Do something important    }  } 

23.錯誤處理

• 當方法通過引用來返回一個錯誤參數，判斷傳回值而不是錯誤變數。

　　應該：

NSError *error;  if (![self trySomethingWithError:&error]) {    // Handle Error  } 

　　不應該：

NSError *error;  [self trySomethingWithError:&error];  if (error) {    // Handle Error  }  

　　在成功的情況下，有些Apple的APIs記錄垃圾值(garbage values)到錯誤參數(如果non-NULL)，那麼判斷錯誤值會導致false負值和crash。

24.單例模式

• 單例對象應該使用安全執行緒模式來建立共用執行個體。

+ (instancetype)sharedInstance {    static id sharedInstance = nil;    static dispatch_once_t onceToken;    dispatch_once(&onceToken, ^{      sharedInstance = [[self alloc] init];    });    return sharedInstance;  }  

　　這會防止possible and sometimes prolific crashes。

25.xcode 工程

• 物理檔案應該與Xcode工程檔案保持同步來避免檔案擴張。任何Xcode分組的建立應該在檔案系統的檔案體現。代碼不僅是根據類型來分組，而且還可以根據功能來分組，這樣代碼更加清晰。
• 儘可能在target的Build Settings開啟"Treat Warnings as Errors，和啟用以下additional warnings。如果你需要忽略特殊的警告，使用Clang‘s pragma feature。

26.其他規範

　　如果我們的編碼規範不符合你的口味，可以查看其他的編碼規範：

• Robots & Pencils
• New York Times
• Google
• GitHub
• Adium
• Sam Soffes
• CocoaDevCentral
• Luke Redpath
• Marcus Zarra

　　

 

[Objective-C] 014_Objective-C 代碼規範指南(上)