总是在任何实例变量的声明前加上@private指令，永远不要在类外面直接访问实例变量。
为什么？
- 将信息隐藏(封装)
- 只在类实现的方法中才去直接访问实例变量
- 实例变量的默认访问属性是@protected，意味着子类可以自由访问这些实例变量。但没有足够的理由不要允许子类这么做——父类暴露给外界的所有东西是它的一种契约，改变类成员的内部表示而不改变它的接口或者契约是面向对象封装的重要好处。将你的实例变量设为私有，你就告诉外界它们是实现的细节而非类的接口
戒律…
总是为每个数据成员创建@property，然后在类实现中用”self.name”去访问它。永远不要直接访问你的实例变量。
为什么?
- 属性强制加上了访问限制(例如readonly)
- 属性强制加上了内存管理策略(strong,weak)
- 属性帮你实现了setter和getter
- 使用属性可以强制执行线程安全策略
- 单一的访问实例变量的方法可以增加代码可读性
好的做法
戒律…
总是在你的属性上加上”nonatomic”，除非你在写线程安全的类，确实需要原子访问，那就在代码中写注释表明你是故意这么做的。
为什么?
那些带有未声明为”nonatomic”属性的类会让人们觉得这是个设计成线程安全的类，但实际上并不是。只有在你确实将类设计成线程安全时，才不要在属性前加上”nonatomic”。
好的做法
好的做法
戒律…
永远不要让你的实例变量名字和属性名或者数据成员名有所混淆。总是在实例变量名结尾加上下划线。 除非你继承了第三方的类，这个类已经有一个数据成员有同样的名字，这样的话就选择一个不同的名字，或者再加一条下划线，然后加入注视解释你为什么要这么做。
在实现中使用”@synthesize name = name_;”，而不要只写”@synthesize name;”
为什么?
- 即使是在类实现中你也最好属性访问器来访问数据成员，而不要直接访问，除非特殊情况。
- 苹果对于他们的私有实例变量用了”_name”的方式，那么你自己的就用”name_”的方式好了，可以避免命名冲突。
- 苹果已经开始在那些应用级的代码示例及模板中使用”name_”的命名习惯。
好的做法
戒律…
永远不要自己在类接口中重复增加数据成员。让@synthesize指令来为你隐式地增加数据成员。
遵从这条经验，许多类可以不用在类接口中显式地声明实例变量。当一个类没有实例变量时，可以省略@private声明，甚至连数据成员段的开闭括号都可以去掉。
为什么?
- 减少重复。
- 简化类的头文件。
- 不需要把类的声明都写在公共头文件中，你可以在实现文件中声明那些真正会直接访问到的类成员。
好的做法
当你自己在为实例变量写setter和getter的时候，如果你在其中需要直接访问变量的话，你得声明名字带下划线的变量：
错误的写法
-
@interface Foo : NSObject
-
@property(strong, nonatomic) NSObject* myObj;
-
@end
-
// …
-
@implementation Foo
-
@synthesize myObj;
-
- ( NSObject*)myObj
-
{
-
return self.myObj; // 会递归调用getter!
-
}
-
- (void)setMyObj:( NSObject*)myObj
-
{
-
self.myObj = myObj; // 会递归调用setter!
-
}
- @end
正确的写法
-
@interface Foo : NSObject
-
@property(strong, nonatomic) NSObject* myObj;
-
@end
-
// …
-
@implementation Foo
-
@synthesize myObj = myObj_;
-
- ( NSObject*)myObj
-
{
-
return myObj_; // 没问题.
-
}
-
- (void)setMyObj:( NSObject*)myObj
-
{
-
// 没问题
-
myObj_ = myObj; // 进行赋值(ARC会处理必要的retain和release)
-
}
- @end
戒律…
NEVER access a data member through an underscore-suffixed symbol UNLESS you are writing a setter or getter.
永远不要访问名字以下划线开头的变量，除非你在写setter或getter。
坏的做法
-
@interface Foo : NSObject
-
@property(strong, nonatomic) Bar* myObj;
-
@end
-
// …
-
@implementation Foo
-
@synthesize myObj = myObj_;
-
- (void)someMethod
-
{
-
myObj_ = [[Bar alloc] init];
-
}
- @end
好的做法
-
@interface Foo : NSObject
-
@property(strong, nonatomic) Bar* myObj;
-
@end
-
// …
-
@implementation Foo
-
@synthesize myObj = myObj_;
-
- (void)someMethod
-
{
-
self.myObj = [[Bar alloc] init];
-
}
- @end
戒律…
永远不要在类的头文件中声明内部(私有)方法或属性。总是将所有的内部方法和属性声明放入实现文件中的“类扩展”中。
坏的做法
-
//
-
// Foo.h
-
//
-
@interface Foo : NSObject
-
@property(nonatomic) int myPublicProperty;
-
@property(strong, nonatomic) Bar* myPrivateProperty; // This can be accessed by anyone who includes the header
-
- (int)myPublicMethod;
-
- (int)myPrivateMethod; // So can this.
- @end
好的做法
-
//
-
// Foo.h
-
//
-
@interface Foo : NSObject
-
// Only the public API can be accessed by including the header
-
@property(nonatomic) int myPublicProperty;
-
- (int)myPublicMethod;
- @end
-
//
-
// Foo.m
-
//
-
@interface Foo () // This is a “class extension” and everything declared in it is private, because it’s in the implementation file
-
@property(strong, nonatomic) Bar* myPrivateProperty;
-
- (int)myPrivateMethod;
-
@end
-
@implementation Foo
-
// …
- @end
戒律…
永远不要在一个方法里有超过一句返回语句，让方法中的最后一个语句带有一个非空值的返回类型。
在返回非空值的方法中，第一句语句就声明一个变量保存返回值，给它一个有意义的默认值。必要时在代码不同路径中给它赋值。在最后一个语句中返回它的值。永远不要过早地用返回语句返回它的值。
为什么?
过早的返回语句会增加有一些必要资源释放没有被执行的可能性。
好的做法
-
@implementation Foo
-
- (Bar*)barWithInt:(int)n
-
{
-
Bar* result = nil;
-
// Allocate some resource here…
-
if(n == 0) {
-
result = [[Bar alloc] init];
-
} else if(n == 1) {
-
result = self.myBar;
-
}
-
// …and deallocate the resource here, you’re done!
-
return result;
-
}
- @end
戒律…
理解自动释放池用来做什么，什么时候为你创建与释放，以及什么时候你需要自己来创建和释放它。
- 由NSRunLoop在每一个循环自动创建及释放
- 由NSOperation自动创建及释放
- 在线程的开始及结尾处手动创建及释放
- 每当你需要在某个循环中创建及释放大量对象的时候，在循环外手动创建及释放
在ARC模式下，你通过@autoreleasepool{…}指令来创建自动释放池。
戒律…
总是倾向于使用类层面的便利构造函数，而非init构造函数。所有基础框架里的容器类都提供这些。
坏的做法
-
NSMutableDictionary* dict = [[ NSMutableDictionary alloc]init];
好的做法
-
NSMutableDictionary* dict = [ NSMutableDictionarydictionary];
戒律…
总是在你所写类的接口中提供类层面的便利构造函数。
为什么?
这样你所写类的使用者就能够遵循上面那条戒律了。
坏的做法
-
@interface Foo : NSObject
-
- (id)initWithBar:(int)bar baz:(int)baz;
-
@end
好的做法
-
@interface Foo : NSObject
-
- (id)initWithBar:(int)bar baz:(int)baz;
-
+ (Foo*)fooWithBar:(int)bar baz:(int)baz;
-
@end
戒律…
一定要理解对象所有权的转移什么时候会发生。ARC会帮你处理很多，但你还是得知道在背后到底发生了什么。
常见的获得对象所有权的方法：
- 当你对一个类调用+alloc的时候你就拥有了新对象。
- 当你对一个实例调用-copy或者-mutableCopy的时候你就拥有了新对象。
- 当你将对象赋值给retain或者strong属性时，你就成为了该对象的拥有者。
常见的释放对象所有权的方法：
- Assign another object (or nil) to a property with the (strong) attribute.
- Let an owning local variable go out of scope.
- Another object holding a reference to the object is destroyed.
- 将另一个对象(或者nil)赋值给strong属性。
- 本来拥有其所有权的一个局部变量超出了其生命周期范围。
- 拥有该对象引用的另一个对象被释放了。
戒律…
一定要理解你属性和实例变量的内存管理策略，尤其当你在写自己的getter和setter时。确保你的实例变量上定义的存储策略是正确的，这样ARC才会正确工作。最简单的办法是单用一个@synthesize，然后覆盖setter及/或getter，在其中访问名字带下划线的实例变量，其行为跟属性中所声明的存储策略是一致的。
-
@interface bar
-
@property (strong, nonatomic) id foo;
-
@end
-
@implementation bar
-
@synthesize foo = foo_;
-
- (id)foo
-
{
-
return foo_;
-
}
-
- (void)setFoo:(id)foo;
-
{
-
foo_ = foo; // Retained/released automatically by ARC because of (strong) attribute on @property above
-
[self syncToNewFoo]; // The reason for our custom setter
-
}
-
@end
戒律…
永远不要在你类中出现-dealloc方法，除非需要释放一些特殊的资源(关闭文件，释放由malloc()申请的内存，使定时器失效等)。其他的事情ARC都会帮你做的。移除nsnotification通知等.
戒律…
只要你为属性加上了自己写的setter，那么总是也要加上自己写的getter，反之亦然。
为什么?
Getter和setter在内存管理、线程安全以及其他一些它们可能会造成副作用的地方需要有对等的行为。你不能指望一个合成的getter或setter能跟一个自己写的getter或setter有对等的行为。因此，如果你打算自己写一个getter或者setter的话，请你两个都写上。
戒律…
如果你总是需要在释放一个对象的时候做一些事情(比如使定时器失效)，那么你一定要为它的属性自己写一个setter，然后在你的-dealloc方法中将属性置为nil。
坏的做法
-
@implementation Foo
-
@synthesize myTimer;
-
- (void)dealloc
-
{
-
self.myTimer = nil; // 定时器没有置为失效，在对象回收后我们可能还会收到回调！
-
}
-
@end
好的做法
为什么?
ARC负责在-dealloc的时候释放你的strong或retain实例变量，但它是直接释放变量，而不会调用你自己写的setter。因此如果你自己写的setter有其他的一些副作用(比如使定时器失效)，你还是得自己去调用它。
戒律…
在写构造函数的时候，一定不要在[super init]调用前写很多代码，写得越少越好。
为什么?
一般情况下，对父类构造函数的调用有肯能会失败，导致调用返回nil。如果发生这样的事，在调用父类构造函数之前你所做的一切初始化工作将变得毫无价值，甚至是有害的，必须要撤销。
戒律…
当你没有使用nib文件在写UIViewController的时候，一定要在-loadView中创建你的视图层次结构，永远不要在-init中做。你只能够在-loadView的实现中对view属性进行赋值。
戒律…
永远不要自己调用-loadView！UIViewController的view属性在它被访问时会懒加载。它也会在低内存情况下被自动清除。因此永远不要假设UIViewController的view会跟controller活的一样长。
戒律…
总是只创建你需要的视图一次，然后在必要时展示、隐藏或移动它们。永远不要在每次一有变化就重复回收和再创建你的视图层次结构。
戒律…
永远不要自己在UIView上调用-drawRect。可以调用-setNeedsDisplay。
戒律…
一定要避免在代码中做很长很复杂的操作。局部变量是你的朋友。
坏的做法
-
NSMutableDictionary* listDict = [[ NSMutableDictionaryalloc] initWithDictionary:[[ NSUserDefaultsstandardUserDefaults] objectForKey:@”foo”]];
好的做法
-
NSUserDefaults* defaults = [ NSUserDefaultsstandardUserDefaults];
-
NSDictionary* dataModelDict = [defaults objectForKey:@"foo"];
-
NSMutableDictionary* listDict = [ NSMutableDictionarydictionaryWithDictionary:dataModelDict];
为什么?
- 自说明
- 易于理解
- 调试器易于追踪代码
戒律…
当你没有在画什么东西的时候，方法名永远不要类似于-drawUI这样。总是用类似于-setupUI或者-resetUI这样的名字，尤其是当方法可能被调用不止一次的时候。
戒律…
永远不要重复。针对每个信息或者功能，都有个地方单独存放，程序中哪里能够用到就部署进去，甚至意味着有时候要触及到他人的代码。永远不要通过复制粘贴来编程。
戒律…
永远不要调用-stringWithString，除非你：
- 正将NSString转为NSMutableString。
- 正将NSMutableString转为NSString。
- 需要保证你正在处理的NSString*确实是不可变的。
- 真的需要一份NSMutableString的拷贝，因为你打算分别修改它们。
为什么?
NSString是不可变的。一定不要去拷贝一个NSString，除非你想要一份可变的拷贝，或者确保一个你想保存的NSString的指针并没有变为NSMutableString的指针(那样的话，之后其他代码可能会改变了它的值)。实际上，试图拷贝NSString的行为仅仅是增加了该字符串的引用计数，然后再返回该字符串本身。
戒律...
对于那些可以接收有可变子类的对象(像NSString或NSArray)的属性，存储类型一定要使用(copy)。
为什么?
属性的(copy)存储类型(还有-copy方法)总是产生这些对象的不可变拷贝。因此你可以依靠这些拷贝的不可变性（译者注：不用担心会改变原来对象的值），而你不能依靠原来对象的不可变性。这也是对调用者的一个承诺：你将不会改变通过这种方式传给你的对象的值，即使你不小心改变了该对象拷贝的值（译者注：也不会影响原对象的值）。
戒律...
When overriding a method in a superclass, ALWAYS call the superclass' implementation,even if you know that super's implementation does nothing, unless you have a very good reason to not call super's implementation, in which case you must document your reason in the comments.
当覆盖父类中的某个方法时，总是要调用父类的实现，即使你知道父类的实现什么事情也没做，除非你有不调用父类实现的很好的理由，这种情况下你必须在注释中写下你的理由。
为什么?
- 父类的实现在将来可能不会一直什么都不做。
- 可能有其他类最终会介入到你的类和你的父类之间，并且对父类的这个方法有一个非空的实现。
- 使你的代码更加能自说明，看你的代码就能知道这是个覆盖父类的方法，因为调用了父类的实现。
好的做法
-
@implementation Foo
-
- (void)awakeFromNib
-
{
-
[super awakeFromNib];
-
// do my setup
-
}
-
@end
戒律...
在条件语句中，永远不要把指针或数值当成布尔值。
为什么?
布尔值有两个值：true和false(按照Objective-C的习惯我们使用YES和NO)。而指针的值是一个对象或者nil。数值的值是某个数或0。在条件语句上下文中，o和nil和布尔值的false是等同的，这是一种形式的隐式类型转换，会让你的代码难以理解。因此要显式的测试这些值，对于指针看它是否等于nil，对于整型看它是否等于0，对于浮点看它是否等于0.0，等等。
坏的做法
-
- (void)fooWithBar:(Bar*)bar baz:(BOOL)baz quux:(float)quux
-
{
-
if(bar && baz && quux) {
-
// do something interesting
-
}
-
}
好的做法
-
- (void)fooWithBar:(Bar*)bar baz:(BOOL)baz quux:(float)quux
-
{
-
if(bar != nil && baz && quux != 0.0) {
-
// do something interesting
-
}
-
}
戒律...
NEVER use conditional statements to check for nil when you don't have to. In particular, understand that in Objective-C, the act of calling any method on a nil object reference is a no-op that returns zero (or NO, or nil), and write your code accordingly.
当没必要的时候，永远不要用条件语句去测试是否为nil。特别的是，在Objective-C里，在nil对象上调用任何方法相当于做了一步返回值为0(或者NO，或者nil)的空操作，你应该相应去写你的代码。
坏的做法
-
- (void)setObj:( NSObject*)obj
-
{
-
if(obj_ != nil) {
-
[obj_ doCleanup];
-
}
-
if(obj != nil) {
-
[obj doSetup];
-
}
-
obj_ = obj;
-
}
好的做法
-
- (void)setObj:( NSObject*)obj
-
{
-
[obj_ doCleanup]; // Does nothing if obj_ == nil
-
[obj doSetup]; // Does nothing if obj == nil
-
obj_ = obj;
-
}
mm
520
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
