Re: "Tricks" of the "Trade"
Re: "Tricks" of the "Trade"
- Subject: Re: "Tricks" of the "Trade"
- From: Christopher Wolf <email@hidden>
- Date: Thu, 7 Jun 2001 09:54:53 -0400
*This message was transferred with a trial version of CommuniGate(tm) Pro*
Use:
NSLog(@"%d", myInt);
The first parameter passed to NSLog should be a printf style format
string not the literal string which you want logged.
Here's a common gotcha... if you write:
NSLog(myString);
it's true that this will NORMALLY just log myString... until myString
has a % character in it and then it'll blow up since it'll interpret it
as a format place-holder.
So you should always write:
NSLog(@"%@", myString);
instead.
- Chris
On Thursday, June 7, 2001, at 02:55 AM, Max J Cantor wrote:
*This message was transferred with a trial version of CommuniGate(tm)
Pro*
YES, i do agree with you, NSLog() is a wonderful tool. But, I have a
question, if you want to NSLog() to print the value of an int, is
there a
better way than NSLog([[NSNumber numberWithInt:i] stringValue])?
-Max
On Thu, 7 Jun 2001, Enrique Zamudio wrote:
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
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev