[var release] code completion Follow Profetas Created April 20, 2011 09:51 How can I change this code? When I declare a variable I would like to have in deallocvar = nil instead of release.Maybe this should be another possible code suggestion.
Filed a request for it - OC-685. You can vote for it.
I expect you want the suggestion to be:
self.var = nil;
aren't you leaking memory, if it's just:
var = nil;
You are right.
self.var = nil; when variable is retain
Actually I would like to have this suggestion in any case, where I have declared a property that allows me to set it using dot-notation - because then I feel confident, that memory management is handled correctly. Of course if the property is declared as readonly, it will not work (and should not be suggested).
I think the suggestion self.var = nil; will be alright if variable is retain or assign - of course if it is assign, then you really don't need to do anything about it, when you're in dealloc - however, I consider it good coding style, because it shows, that you're aware of the variable - and *if* somebody should change the property from assign to retain later on, then dealloc does not need to be modified.
If property is assign, inserting "self.prop = nil" is incorrect, because it won't release the underlying ivar.
Fixed. The option is in Preferences | Code Style | Code Generation.
I would beg to differ.
If property is assign, you have not retained when the value was initially set - therefore you should not release.
This is in fact my best argument for using self.ivar = nil; in dealloc. It will do the correct thing regardless of whether you set the property to retain or assign. (unless you have manually implemented the setter) :-)
Thanks for fixing...
I meant if we have "ivar = [class retain]" and some property was synthesized with this ivar with "assign" attribute, we'll have to put "[ivar release]" to dealloc method, "self.property = nil" will be incorrect here.
I agree with you on that.
However, I would consider it bad practice to declare a property with assign, and then do stuff in my implementation where I actually retained it - how about having an intention to warn about that? :-)