Re: Coding Standards For Objective C
Re: Coding Standards For Objective C
- Subject: Re: Coding Standards For Objective C
- From: "M. Uli Kusterer" <email@hidden>
- Date: Thu, 25 Nov 2004 21:47:50 +0100
At 13:58 Uhr -0600 24.11.2004, Ricky Sharp wrote:
(1) all instance variables (members) are prefixed with 'm'
e.g.: float mShadowOffset;
Generally, in ObjC, instance variables are named the same as their
accessor. So I wouldn't use an "m" prefix.
(2) all parameters are prefixed with in, out, or io to denote usage
e.g.: int foo (int inAddend, int inAugend, int& outSum)
Yup, that's a good idea. I usually use outXXX or ioXXX on output
parameters (depending on whether they're output-only or whether you
pass something in and it's modified). Usually I'm too lazy to label
all params as "in", especially if they're no pointer- or
reference-types, though.
(3) Because of the prefix rules above, all local variables would not
have any prefix. Thus, locals var names never collided with ivars
or parameters.
I used to use a "v" prefix on locals. But usually I just rely on GCC
to flag any collisions for me, and use readable names instead. All
these prefixes make reading code so much harder.
When I first starting migrating to Cocoa, I kept this naming
convention. To me, it helped readability. Plus I would never get
compiler warnings such as "local declaration of 'buttonStyle' hides
instance variable" when I accidentally named a local variable the
same as an ivar.
Well, it's not bad to get these warnings as long as one fixes the
code afterwards. Actually, I'm happy for everything a language and
its compiler do that I don't have to take care of.
Is anyone else doing something similar? Is this to be frowned upon?
I have no problem in changing my practices to adhere to the
guidelines.
Well, prefixes actually decrease readability. You're already used to
those prefixes, so you hardly notice them, and if you have lots of
instance variables and locals with similar names it becomes easy to
mix them up (even with prefixes, though... one of my more recurring
coding errors :-).
I personally love ObjC's more verbose syntax, so I'm often doing
away with prefixes to make sure the code reads better. I always find
myself making a sub-second pause when I come across a prefix.
If I do change my code, one thing that becomes a pain is the whole
local variable named the same as an ivar.
Well, the compiler catches those, but if that's painful to you, I
guess prefixing locals with "a", "an" or "the" should solve the
problem.
What I've been finding is that a method often needs the value from
some accessor in several points. I am often tempted to declare a
local variable so I can reuse that value throughout. (...) Also, for
foo, should I really be calling the accessor everywhere rather than
having a local?
It's good OO-design to never *bypass* the accessor, but caching the
value in a local variable is a valid form of design, I'd personally
say. I usually do that to save myself some typing or make code more
readable. Of course, as with all caches, you run the risk of stale
caches, depending on your algorithm, whether you have several threads
etc. It's a trade-off: If you think it could become a problem later,
don't do it. Otherwise, feel free.
Don't bother doing that for speed optimizations, though. Profile
your code before you start wildly optimizing (if you're uncomfortable
with Shark, there are ways to do it manually, but *do* profile). In
most cases, if it's really speed-critical, you'll want to build the
cache into the accessor instead of having an external cache. That way
you don't violate encapsulation, and the class itself usually knows
much better whether it needs to re-cache.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden