Programming Language ကို ရေးတဲ့အခါမှာ တစ်ယောက်နဲ့ တစ်ယောက် ရေးသားတဲ့ style တွေ က မတူညီကြပါဘူး။ ဒါကြောင့် ရေးသားပုံ တူညီအောင် style guide တွေ ထုတ်ကြပါတယ်။ Company တော်တော်များများကလည်း style guide တွေ ထုတ်ပြီး ရုံးအတွင်း project ရဲ့ code တွေရဲ့ style တွေ တူညီအောင် ဖန်တီးကြပါတယ်။ Objective-C မှာလည်း style guide တွေ ရှိပါတယ်။ ကျွန်တော်ကတော့ The New York Time ရဲ့ iOS team က ထုတ်ထားတဲ့ style guide ကို လိုက်နာပါတယ်။ အရင်လမှာတော့ Part 1 ကို ဖော်ပြပြီးပါပြီ။ ဒီလမှာတော့ ကျန်တဲ့ အပိုင်း ၂ ကို ဆက်လက် ဖော်ပြလိုက်ပါတယ်။
comments တွေ ရေးဖို့လိုတဲ့ အခါမှာ why ကို ရှင်းပြပေးဖို့လိုပါတယ်။ comments အားလုံးတွေဟာ up-to-date ဒါမှမဟုတ် မရှိတော့တာတွေကို ဖျက်ထားပေးဖို့လိုပါတယ်။
Block comments ကို တတ်နိုင်လျှင် ရှောင်ရှားသင့်ပါတယ်။ code တွေဟာ self-documenting ဖြစ်ဖို့လိုပါတယ်။ စာကြောင်း အနည်းငယ်နဲ့ ရှင်းပြထားဖို့သာ လိုအပ်သည်။ ထိုရှင်းပြထားသည်များကို documentation generate လုပ်တဲ့ အခါတွင် အသုံးပြုမှာ မဟုတ်ပါဘူး။
dealloc
methods တွေဟာ ထိပ်မှာ implementation လုပ်ထားဖို့လိုပါသည်။ @synthesize
နှင့် @dynamic
အပြီးတွင် ရေးဖို့လိုသည်။ init
ဟာ class ရဲ့ dealloc
method အောက်တွင် ရေးဖို့လိုသည်။
init
method သည် အောက်ပါ ပုံစံ ဖြစ်ရမည်။
- (instancetype)init {
self = [super init]; // or call the designated initalizer
if (self) {
// Custom initialization
}
return self;
}
NSString
, NSDictionary
, NSArray
, နှင့် NSNumber
တို့ကို imutable instance objects တွေ ဖန်တီးတဲ့ အခါမှာ အသုံးပြုပါ။ nil
value ကို NSArray
နှင့် NSDictionary
တို့၏ literals တွင် ထည့်သွင်းလို့ မရပါ။ crash ဖြစ်နိုင်သည်။
ဥပမာ :
NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingZIPCode = @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 *buildingZIPCode = [NSNumber numberWithInteger:10018];
CGRect
ရဲ့ x
, y
, width
, သို့မဟုတ် height
တို့ကို access လုပ်တဲ့ အခါမှာ direct struct ခေါ်မည့်အစား CGGeometry
functions ကို အသုံးပြုပါ။
Apple’s CGGeometry
reference တွင် ဖော်ပြထားသည်မှာ :
All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.
ဥပမာ:
CGRect frame = self.view.frame;
CGFloat x = CGRectGetMinX(frame);
CGFloat y = CGRectGetMinY(frame);
CGFloat width = CGRectGetWidth(frame);
CGFloat height = CGRectGetHeight(frame);
ဒီလို မသုံးပါနှင့်:
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;
Constans တွေကို in-line string literals သို့မဟုတ် numbers အနေဖြင့် အသုံးပြုသင့်သည်။ search and replace လုပ်စရာမလိုပဲ value ကို လွယ်လင့်တကူ ပြောင်းလဲနိုင်ရန် အတွက် ဖြစ်သည်။ Constanst တွေကို static
ကြေငြာပါ။ macro မှ လွဲ၍ define
ကို ဖြစ်နိုင်လျှင် အသုံးမပြုပါနှင့်။
ဥပမာ :
static NSString * const NYTAboutViewControllerCompanyName = @"The New York Times Company";
static const CGFloat NYTImageThumbnailHeight = 50.0;
ဒီလို မသုံးပါနှင့် :
enum
ကို အသုံးပြုတဲ့ အခါမှာ underlying type ကို သေသေချာချာကြေငြာခဲ့ဖို့ လိုပါတယ်။ code completion ကို အထောက်အကူပြုရန် အတွက်ဖြစ်ပါသည်။ SDK တွင် underlying ကို NS_ENUM()
macro ကို အသုံးပြုပြီး ရေးနိုင်ပါသည်။
ဥပမာ:
typedef NS_ENUM(NSInteger, NYTAdRequestState) {
NYTAdRequestStateInactive,
NYTAdRequestStateLoading
};
Priavte properties တွေဟာ class ရဲ့ implementation file မှာ class extension (anonymous categories) အနေနဲ့ ကြေငြာသင့်ပါတယ်။
ဥပမာ:
@interface NYTAdvertisement ()
@property (nonatomic, strong) GADBannerView *googleAdView;
@property (nonatomic, strong) ADBannerView *iAdView;
@property (nonatomic, strong) UIWebView *adXWebView;
@end
ပုံနာမည်ပေးတဲ့ အခါမှာ အသုံးပြုရမည့်ပေါ်မှာမူတည်ပြီးတော့ camel case ပုံ နာမည်ပေးသင့်ပါသည်။ အကယ်၍ တစ်ခုတည်းတွင် အသုံးပြုမည် ဆိုပါက နာမည်ရဲ့ ရှေ့မှာ အသုံးပြုမည့် class ဒါမှမဟုတ် protoerty ရဲ့ အမည်ကို ရှေ့တွင် ထည့်သွင်းရေးသားသင့်သည်။
ဥပမာ:
RefreshBarButtonItem / RefreshBarButtonItem@2x
နှင့်
RefreshBarButtonItemSelected / RefreshBarButtonItemSelected@2x
ArticleNavigationBarWhite / ArticleNavigationBarWhite@2x
နှင့်
ArticleNavigationBarBlackSelected / ArticleNavigationBarBlackSelected@2x
ပုံတွေကို အသုံးပြုမည့် ပုံစံ တူညီပါက group ဖွဲ့ပြီး images folder တွင် သိမ်းထားသင့််သည်။
nil
သည် NO
ဖြင့် အတူတူဖြစ်သည်။ ထို့ကြောင့် nil
ကို ထည့်သွင်း စစ်ဆေးနေရန် မလိုပါ။ YES
ကို တိုက်ရိုက် compare မလုပ်သင့်ပေ။ YES
သည် 1 ဖြင့် အတူတူဖြစ်ပြီး BOOL
ဟာ 8 bits ကို အသုံးပြုထားသည်။
ဥပမာ:
if (!someObject) {
}
ဒီလို မသုံးပါ:
if (someObject == nil) {
}
BOOL
, အတွက် နောက်ထပ် ဥပမာ:
if (isAwesome)
if (![someObject boolValue])
’ဒီလို မသုံးပါ:
if ([someObject boolValue] == NO)
if (isAwesome == YES) // Never do this.
အကယ်၍ BOOL
protpery name ဟာ adjective ဖြစ်ခဲ့လျှင် is prefix ကို မသုံးလျှင်ရသည်။ သို့ပေမယ့် get accessor တွင် ထည့်သွင်းရေးပါ။
ဥပမာ :
@property (assign, getter=isEditable) BOOL editable;
စာ နှင့် ဥပမာ ကို Cocoa Naming Guidelines မှ ကူးယူးဖော်ပြထားသည်။
Singleton objects ဟာ shared instance တွေ ဖန်တီးရာမှာ thread-safe pattern ဖြစ်အောင် အသုံးပြုသင့်သည်။
```objc
(instancetype)sharedInstance { static id sharedInstance = nil;
static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ sharedInstance = [[self alloc] init]; });
return sharedInstance; }
တစ်ခါတစ်လေ prolific crashes ဖြစ်ခြင်းကို ကာကွယ်နိုင်သည်။
physical files များသည် Xcode projects files ဖြင့် sync ဖြစ်နေရမည်။ file များ ပြန့်ကျဲ နေမှု မရှိအောင် ထားရမည်။ Xcode groups ဖန်တီးမှုသည် file system ထဲရှိ folder တွင် လည်း သက်ရောက်မှု ရှိရမည်။ Code တွေကို type ဖြင့် group လုပ်ရုံသာ မက အသုံးပြုမည့် fetuare ပေါ်မူတည်ပြီးတော့လည်း group လုပ်သင့်သည်။
ဖြစ်နိုင်လျှင် target’s Build Settings ထဲတွင် “Treat Warnings as Errors” ကို အမြဲတန်း turn on လုပ်ထားရမည်။ additional warnings တွေကို ဖြစ်နိုင်သလောက် enable လုပ်ထားရမည်။ အချို့ warning တွေကို ignore လုပ်လိုလျှင် Clang’s pragma feature ကို အသုံးပြုပါ။
အကယ်၍ ယခု style guide ကို သင် မနှစ်သက်ပါက အခြား style guides များကိုလည်း လေ့လာဖတ်ရှု နိုင်ပါသည်။
Guide အစ အဆုံးကို github မှာ ဖတ်လို့ရပါတယ်။