Re: "Tricks" of the "Trade"
Re: "Tricks" of the "Trade"
- Subject: Re: "Tricks" of the "Trade"
- From: Enrique Zamudio <email@hidden>
- Date: Thu, 7 Jun 2001 00:25:47 -0500
I have to disagree with a couple of points here:
1. For NSArrays, NSDictionarys and their Mutable subclasses, use
[[ClassName alloc] init] as opposed to [ClassName arrayWithCapacity:4]
and their ilk, this tip has proved invaluable to my programs as it is
the only way to allocate them without a hitch.
This may lead to some serious memory leaks. The difference between NSArray'
s +arrayWithObjects: and -initWithObjects: (the class and the instance
method) is that the class method returns an autoreleased object, and the
instance method returns a retained object. If you create a NSArray with
[[NSArray alloc] initWithObjects:...] and you don't release it later, you
will be leaking memory (the array will never go away). This can be a big
deal if you do that from within a big loop or some similar situation.
If, on the other hand, you create an autoreleased object, then you don't
have to worry about releasing it when you're done with it. You can pass it
around and if someone else needs it, they can just retain it and it won't
be released and the end of the event.
2. Don't try to make things optimized on the first try! Check out my
single line of code that resulted from this:
[code removed]
Well that code would work the same if you split it into different lines.
There might be a slight performance increase or decrease; however, it
would be much more readable for another human being.
6. Use subroutines, even inline ones if necessary, it removes clutter
from each source code file, and spreads it out.
The drawback of this is that it breaks the Object Oriented paradigm. I
only do this when performance is a big issue.
7. Use categories to extend features if possible, only use subclasses if
necessary.
I would go the other way around, actually. If you don't need to inherit
functionality from any existing class, you can just write a subclass of
NSObject. But if you need a textfield that does something a NSTextField
can't do, then you write a subclass of NSTextField. You should write a
category on NSTextField only if you need existing textfields in your app
(or a bundle that you load, for that matter) to do something they
regularly can't.
However, I agree with some other points, like comenting code, following
the Aqua HUI guidelines, and starting small. IB's test interface feature
is a GREAT time saver. And does anyone besides me think that NSLog is a
very very useful debugging tool?
Cheers,
eZL
Enrique Zamudio Lopez
Chief Software Architect
North American Software
email@hidden
www.nasoft.com.mx