It's best practice to release your instance variables first, and then set them to nil in your -dealloc method. I personally like doing that like so:
[myVar release], myVar = nil;
If you set your instance variables to nil, you're not releasing them, and you're causing a memory leak. Setting them to nil after releasing though will ensure that you're not causing leaks, and if, for some reason, you try to access those instance variables later, you're not going to get garbage memory.
If you have an instance variable set up as such,
@property (retain) NSObject *myVar;
then it is not a good idea to call self.myVar = nil; during deallocation. If you have objects that have registered for KVO notifications on your instance variable, calling self.myVar = nil will send those notifications, and other objects will be notified, which is bad because they will be expecting you to still be in a valid state—you're not if you're in the deallocation process.
Even if they're not registered for KVO notifications, it's still not a good idea to do that because you should never call methods that could rely on your object's state when its state is inconsistent (some variables might/will be nonexistent), and you should simply handle the process yourself. [myVar release], myVar = nil; will suffice.
If you want more information, read Dave DeLong's answer to this question.
For initializing, it is also not good to call property setters and getters (for much the same reason as above). In an -init call, you would set up the aforementioned variable as such:
myVar = nil; // If you want to set it up as nil.
OR
myVar = [[NSObject alloc] init]; // Or set it up as an actual object.
Avoid self.myVar = nil and self.myVar = [[NSObject alloc] init in cases where your class is in an undeterminate state (these calls are fine in -viewDidLoad and -awakeFromNib, though, because by that point, your class has been completely initialized, and you can rely on the instance variables to be in a complete state).
