Cocoa coding style (was Re: Did I reinvent the wheel?)
Cocoa coding style (was Re: Did I reinvent the wheel?)
- Subject: Cocoa coding style (was Re: Did I reinvent the wheel?)
- From: Chris Hanson <email@hidden>
- Date: Fri, 9 May 2008 19:41:16 -0700
On May 9, 2008, at 11:10 AM, Western Botanicals wrote:
I would like your opinions about the following framework.
http://www.justingiboney.com/code
I've looked at this again, and I really, strongly recommend that you
stop following Java coding style and instead follow Cocoa coding style
for anything you write in Objective-C. They are different platforms
with different community norms.
Here are a few things I think you should do to your code both to
conform to Cocoa coding style and to just make it easier to read from
a general perspective.
(1) Stop indenting the contents of @implementation blocks. I know
you're used to it from Java, but it makes your code really hard to
read for other Cocoa developers.
(2) Set the Xcode editor to use spaces instead of tabs. Tab will
still indent, but the indentation will be represented automatically as
spaces in your file rather than as tabs. This means your code will
look the same as when you wrote it no matter what the user is looking
at it in. (Otherwise, whether and how anything in the code lines up
is at the whim of what "tab" means; that's what finally converted me
from hard tabs to soft tabs...)
(3) Stop trying to "enforce" singletons! Your unit tests will thank
you. And do not override any of the following to implement
singletons! -allocWithZone: -copyWithZone: -retain -retainCount -
release -autorelease Instead, just add a "+sharedWhatever" class
method.
(3) Avoid using "get" as a prefix on accessor methods. This means
something different in Cocoa. Instead, the name of an accessor should
just be the name of the property itself.
(4) Use Objective-C 2 properties rather than writing all your own
accessor methods.
(5) The Objective-C type is BOOL, not bool. The latter is a C++
type. It will be unfamiliar to Objective-C developers and what's
vastly more important, it may @encode differently than the Objective-C
type does.
(6) Leverage Cocoa framework features in your own code. For example,
you don't need to have setter methods that invoke -setDirty:. You can
just write a method like this
- (NSSet *)keyPathsForValuesAffectingDirty {
return [NSSet setWithObject:@"UUID"];
}
and then anything that cares about whether a particular object is
dirty can observe its "dirty" property. Obviously this means you'll
need to understand what Cocoa means by properties, observing, key
paths, and so on — but you need to understand this anyway to be an
effective Cocoa developer.
(7) You "override" methods in subclasses, you don't "overwrite" them.
Using the right terms will make it easier to search the code later.
Finally, some general advice: Consider why you're following the
patterns you are in implementing this. You say
What I have been taught, is to use a framework like the one above,
only I was taught in Java.
You should really examine what it is you're trying to accomplish, try
to find out if there are any frameworks you can leverage, and perhaps
ask the community how it would accomplish that task. Don't just
assume that the way you were taught to do things in Java is the best
way to do them in Objective-C and Cocoa.
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden