Re: Objective-C Instance Variable Names
Re: Objective-C Instance Variable Names
- Subject: Re: Objective-C Instance Variable Names
- From: Scott Andrew <email@hidden>
- Date: Sun, 6 Apr 2008 21:17:53 -0700
You aren't supposed to EVER use direct ivar acess. Every document i
have ever read regarding ObjectiveC has always said to define
acessors. So what prefix you use on your ivars don't matter. To set
m_object. I am going to either define get/set functions or use
properties. This of course depends on if the project is Objective C
1.0 or 2.0. I think style is a very personal thing.
Scott
On Apr 6, 2008, at 4:39 PM, John Stiles wrote:
You can't be KVC compliant if you use prefixes like m_, so this
limits your potential for using things like bindings.
When I write C++, I am also a fan of m_, but it's just not
appropriate for Cocoa since it basically means you're fighting
against the frameworks.
Scott Andrew wrote:
See i still use m_xxx. Alot of it is just old habit from C++ land.
But it really stands out to me m_ tells me its a member. We are
also converting a lot non-mac programmers to mac so I think for
them it makes the code a bit easier to read. I don't use the how
hungarian (lpcstr for consant string etc), but definately prefer
m_myTitle to _myTitle. Again m_ to me just screams member.
I have also always reserved the use of "the" for globals. To me is
says a single instance not a ivar. theWebConnection says there is
one global web connection.
So does this mean I am the laughing stock of the Obj-C collective..
I hope not. I think that style (unless enforced by job) is a
personal preference.
Scott
On Apr 3, 2008, at 10:58 AM, Rob Napier wrote:
On Thu, Apr 3, 2008 at 12:45 PM, Jens Alfke <email@hidden>
wrote:
On 3 Apr '08, at 9:29 AM, Richard Somers wrote:
There is a common practice of prefixing instance variable names
with "_",
a single underscore character.
And it's a very good idea to do so, IMHO. (The exact prefix isn't
important, just as long as it's easy to distinguish ivars from
local vars at
a glance.)
Apple reserves the use of leading underscores for it's own use:
http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingBasics.html#/
/apple_ref/doc/uid/20001281
While they append the phrase "especially in methods," they do mean
for
everything, and you can collide with them if you name your own
identifiers
(including instance variables) with leading underscores.
I used to agree with your sentiment on distinguishing ivars with
local vars
until I discovered the following:
1. Leading underscores really will cause you to collide with Apple
and it
really did blow up in my face.
2. Leading "m" makes you look like a C++ programmer and other ObjC
programmers will laugh at you. You can take that for what it's
worth, but
it's worth keeping in mind if you're going to work on large
projects with
other programmers. "Other ObjC programmers will laugh at you"
seems to be a
common mechanism for keeping large projects sane. Java guys use
their
compiler. We use peer pressure. Which you think is a better way to
enforce
good practice will determine whether you are happier as a Java or
ObjC
programmer.
3. XCode 3 now provides good color coding to distinguish ivars
from local
vars.
4. And besides, if you would use accessors properly, ivars should
very
seldom show up in your code so you shouldn't have confusion (this
being the
cause of #2 above).
Personally, I find the lack of good naming conventions for instance
variables one of the few things that annoys me in ObjC. That said,
I've
found that with proper accessor usage, it doesn't really matter,
and with
XCode3 you can do fine even without proper accessor usage.
But in any case, you shouldn't use underscores.
-Rob
--
Rob Napier -- Software and Security Consulting -- http://robnapier.net
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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