Objective-C Instance Variable Names

  • There is a common practice of prefixing instance variable names with
    "_", a single underscore character.

    If Objective-C 2.0 properties are used this would result in dots
    followed by underscores when invoking accessor methods with the dot
    syntax. Not a desirable situation.

    It appears that Apple as of Mac OS 10.5 uses properties only in Core
    Animation classes and NSPointerFunctions.h with CALayer.h being the
    single biggest user. Nowhere when Apple uses properties does it also
    prefix instance variables with an underscore that I can find. Note
    that NSPointerFunctions.h contains some very interesting property
    examples.

    It would appear then that the practice of practice of prefixing
    instance variable names with an underscore character is becoming a
    historical relic of the past.

    Any comments?

    Regards, Richard
  • On Thu, Apr 3, 2008 at 9:29 AM, Richard Somers
    <rsomers.lists...> wrote:
    > There is a common practice of prefixing instance variable names with "_", a
    > single underscore character.
    >
    > If Objective-C 2.0 properties are used this would result in dots followed
    > by underscores when invoking accessor methods with the dot syntax. Not a
    > desirable situation.
    >
    > It appears that Apple as of Mac OS 10.5 uses properties only in Core
    > Animation classes and NSPointerFunctions.h with CALayer.h being the single
    > biggest user. Nowhere when Apple uses properties does it also prefix
    > instance variables with an underscore that I can find. Note that
    > NSPointerFunctions.h contains some very interesting property examples.
    >
    > It would appear then that the practice of practice of prefixing instance
    > variable names with an underscore character is becoming a historical relic
    > of the past.
    >
    > Any comments?

    There's no reason that the property's name need match the instance
    variable's name exactly:

    @interface MyObject : NSObject {
      id _ivar;
    }

    @property ivar;
    @end

    @implementation MyObject
    @synthesize ivar=_ivar;
    @end

    --
    Clark S. Cox III
    <clarkcox3...>
  • 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.)

    > If Objective-C 2.0 properties are used this would result in dots
    > followed by underscores when invoking accessor methods with the dot
    > syntax. Not a desirable situation.

    Properties and ivars are not the same thing. Properties are shorthand
    for methods, not variables. A property doesn't have to correspond to
    any instance variable, or to one with the identical name.

    > It appears that Apple as of Mac OS 10.5 uses properties only in Core
    > Animation classes and NSPointerFunctions.h with CALayer.h being the
    > single biggest user.

    They just didn't feel it was worth it to rewrite hundreds of existing
    AppKit and Foundation header files replacing all the getter/setter
    method declarations with the equivalent "@property"s. It doesn't
    really make a difference, because you can still use property syntax
    when referring to attributes that have getters or setters — for
    example "window.frame" or "string.length". I do it all the time, it
    saves typing and keeps me from having to count so many nested brackets.

    —Jens
  • On Thu, Apr 3, 2008 at 12:45 PM, Jens Alfke <jens...> 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
  • On 3 Apr 2008, at 19:58, Rob Napier wrote:

    > 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.

    As a Smalltalk programmer (although I don't get to do much Smalltalk
    programming these days) I stick with the following naming convention
    from the Smalltalk days:

    A. Arguments are usually called something like "aName", "anAddress" etc.
    B. Local variables are usually named in their generic form, eg "name".
    C. Instance variables are usually named like "theName", "theAddress"
    or something else that makes sense if there's the risk of mixup
    between ivars and locals.

    "Usually" and "makes sense" are the key phrases here.

    Using leading underscores or even worse, hungarian notation, gives me
    sore eyes and makes the code hard to read.

    On a side note, I learned C++ back in the late 80's from a guy named
    Dr Bjarne Stroustrup. He didn't use hungarian or leading underscores.
    I believe both conventions were introduced much later by Microsoft, if
    my memory serves me right.

    Robert
  • I'd never heard the Smalltalk conventions before, but I have to admit I
    really like the sound of them. I'd love to see a block of code written
    to these rules to see how it plays out in practice. (ObjC or C++, that
    is, not Smalltalk.)

    Robert Claeson wrote:
    >
    > On 3 Apr 2008, at 19:58, Rob Napier wrote:
    >
    >> 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.
    >
    > As a Smalltalk programmer (although I don't get to do much Smalltalk
    > programming these days) I stick with the following naming convention
    > from the Smalltalk days:
    >
    > A. Arguments are usually called something like "aName", "anAddress" etc.
    > B. Local variables are usually named in their generic form, eg "name".
    > C. Instance variables are usually named like "theName", "theAddress"
    > or something else that makes sense if there's the risk of mixup
    > between ivars and locals.
    >
    > "Usually" and "makes sense" are the key phrases here.
    >
    > Using leading underscores or even worse, hungarian notation, gives me
    > sore eyes and makes the code hard to read.
    >
    > On a side note, I learned C++ back in the late 80's from a guy named
    > Dr Bjarne Stroustrup. He didn't use hungarian or leading underscores.
    > I believe both conventions were introduced much later by Microsoft, if
    > my memory serves me right.
    >
    > Robert
    >
    > ------------------------------------------------------------------------
  • On Thu, Apr 3, 2008 at 7:08 PM, Robert Claeson <robert...> wrote:

    > C. Instance variables are usually named like "theName", "theAddress" or
    > something else that makes sense if there's the risk of mixup between ivars
    > and locals.

    Myself I use "myName" for instance variables and "theName" for static
    variables. (I guess I'd probably use "globalName" if circumstances
    ever dictated.)

    Hamish
  • On Apr 3, 2008, at 1:29 PM, Hamish Allan wrote:

    > On Thu, Apr 3, 2008 at 7:08 PM, Robert Claeson <robert...>
    >> wrote:
    >
    >> C. Instance variables are usually named like "theName",
    >> "theAddress" or
    >> something else that makes sense if there's the risk of mixup
    >> between ivars
    >> and locals.
    >
    > Myself I use "myName" for instance variables and "theName" for static
    > variables. (I guess I'd probably use "globalName" if circumstances
    > ever dictated.)

    Here's another vote for using "myName" - after all, when you add an
    instance variable to a class in IB it is "myVariable".  Plus if you
    ever directly try to access another objects ivars it looks wrong
    grammatically "someObject->myStuff" (using this guideline would make
    "its" a bad prefix for stuff not meant to be publicly visible).

    Glenn Andreas                      <gandreas...>
      <http://www.gandreas.com/> wicked fun!
    quadrium2 | build, mutate, evolve, animate  | images, textures,
    fractals, art
  • On 3 Apr '08, at 10:58 AM, Rob Napier wrote:

    > Apple reserves the use of leading underscores for it's own use:
    > 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.

    This issue came up several times while I was at Apple. The most recent
    consensus (involving members of the Cocoa and compiler groups) was
    that "_" prefixes for ivar names are mostly harmless, though they
    should be avoided in method names. The reason is that ivar names are
    less dynamic. If in the next OS release a system superclass of your
    class adds an ivar with the same name, it's not a binary compatibility
    problem (your class will continue to work, because its machine code
    references the ivar as a numeric offset into the instance data, not by
    name.) Whereas if a superclass adds a _method_ with the same name as
    yours, all hell may break loose because your method will get called
    instead.

    Now, your code will break when you try to recompile it using the new
    headers, because the compiler will complain about the ivar name
    conflict. But then you just rename your ivar. It's a less serious
    problem because it doesn't break any copies of the app that are out in
    the field.

    > 1. Leading underscores really will cause you to collide with Apple
    > and it really did blow up in my face.

    Was it with a method or an ivar name?

    > 3. XCode 3 now provides good color coding to distinguish ivars from
    > local vars.

    I should try turning that specific color code on. I turned off all the
    new Xcode 3 color coding because there were too many different colors
    and it made the code look garish.

    > 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).

    I don't use accessors properly, then. ;) Method calls are so expensive
    compared to ivar accesses that I don't use them for accessing instance
    data, unless the accessor is nontrivial or the setter call is needed
    to trigger KV notifications. (Also, I generally don't declare
    properties for internal state that isn't part of the class's public
    API.)

    —Jens
  • El 03-04-2008, a las 16:19, <cocoa-dev-request...> escribió:

    > On 3 Apr '08, at 10:58 AM, Rob Napier wrote:
    >
    >> Apple reserves the use of leading underscores for it's own use:
    >> 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.
    >
    > This issue came up several times while I was at Apple. The most recent
    > consensus (involving members of the Cocoa and compiler groups) was
    > that "_" prefixes for ivar names are mostly harmless, though they
    > should be avoided in method names. The reason is that ivar names are
    > less dynamic. If in the next OS release a system superclass of your
    > class adds an ivar with the same name, it's not a binary compatibility
    > problem (your class will continue to work, because its machine code
    > references the ivar as a numeric offset into the instance data, not by
    > name.) Whereas if a superclass adds a _method_ with the same name as
    > yours, all hell may break loose because your method will get called
    > instead.
    >
    > Now, your code will break when you try to recompile it using the new
    > headers, because the compiler will complain about the ivar name
    > conflict. But then you just rename your ivar. It's a less serious
    > problem because it doesn't break any copies of the app that are out in
    > the field.
    >
    >> 1. Leading underscores really will cause you to collide with Apple
    >> and it really did blow up in my face.
    >
    > Was it with a method or an ivar name?
    >
    >> 3. XCode 3 now provides good color coding to distinguish ivars from
    >> local vars.
    >
    > I should try turning that specific color code on. I turned off all the
    > new Xcode 3 color coding because there were too many different colors
    > and it made the code look garish.
    >
    >> 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).
    >
    > I don't use accessors properly, then. ;) Method calls are so expensive
    > compared to ivar accesses that I don't use them for accessing instance
    > data, unless the accessor is nontrivial or the setter call is needed
    > to trigger KV notifications. (Also, I generally don't declare
    > properties for internal state that isn't part of the class's public
    > API.)
    >
    > —Jens
    > -------------- next part --------------
    > A non-text attachment was scrubbed...
    > Name: smime.p7s
    > Type: application/pkcs7-signature
    > Size: 1875 bytes
    > Desc: not available
    > Url : http://lists.apple.com/pipermail/cocoa-dev/attachments/20080403/a3d0ef05/sm
    ime.bin


    I just name the all my instance variables  "the_instance_var_" , and
    the local ones "theLocalVar", this keep me well informed about if X
    var is instance or local :).

    Mario Gajardo Tassara
    <marioegt...>
  • I didn't notice the Xcode syntax-coloring of the instance variables --
    I'll have to try using that.

    There's another solution besides naming conventions. I've been through
    most of them -- underscore prefix or postfix, prefix with "m" etc. I
    generally don't find naming conventions very satisfactory. It seems
    like I'm trying to encode something into the name that should be
    evident from the syntax of the language or the context the variable is
    used in.

    So the solution I am toying with, which I think most people won't like
    because it is quite verbose, harkens back to the old days of
    programming on the Mac. If you ever used the MacApp application
    framework (in its original incarnation) you used Object Pascal, and in
    Object Pascal all instance variables had to be referenced as members
    of "SELF", so for instance you'd have to write something like
    "SELF.myVariable := 2;"

    When the framework was converted to C++, one of the complaints that
    some MacApp programmers had was that the C++ syntax would be less
    clear in particular regarding instance variables, where you could
    write "myVariable = 2;" and it wasn't clear whether "myVariable" was
    an instance variable or not. The Object Pascal syntax always made it
    clear whether the variable was an instance variable without having to
    refer back to the object declaration.

    It was pointed out to these people that you could just as easily use
    the equivalent "this->myVariable = 2;" I believe the MacApp code
    itself made heavy use of this convention. This mollified some Object
    Pascal fans.

    I'm toying with doing this in my new project, just because I dislike
    coding properties like this into the name. I'm naming my instance
    variables anything I want to and then consistently referring to them
    with self->myVariable (to access the raw ivar) or self.myVariable if I
    want to use the accessor.

    So far it seems to be OK, except that I don't particularly like the
    looks of it when used as the target of a message (as in "[self->target
    method];") although I don't have a rational reason for that opinion.

    - Dennis D.
  • On Apr 5, 2008, at 15:44, Dennis C. De Mars wrote:

    > There's another solution besides naming conventions. I've been
    > through most of them -- underscore prefix or postfix, prefix with
    > "m" etc. I generally don't find naming conventions very
    > satisfactory. It seems like I'm trying to encode something into the
    > name that should be evident from the syntax of the language or the
    > context the variable is used in.

    I think the issue with all the solutions suggested so far (myWhatever,
    theWhatever, aWhatever, mWhatever, lpWhatever, _whatever, self-
    > whatever) is that they're trying to encode primarily *syntactic*
    information into the variable name. While there's nothing wrong with
    that, some of us (including you, it seems from your comments) find it
    somehow ugly or redundant or ... something.

    Another approach is to qualify the property name *semantically*
    instead. The most common situation where I run into local/instance
    variable name conflicts is setter methods. If the property and the
    instance variable are both 'whatever', it makes sense to me to call
    the setter argument variable 'newWhatever', because that is in fact
    what it is. That makes it natural, when you need to move the instance
    variable into a local variable, as often happens when releasing and
    retaining, to call it 'oldWhatever'.

    In other scenarios, other choices suggest themselves. Sometimes it
    makes sense to call a local copy of the instance variable
    'currentWhatever'. For arguments to initializers, where a value is
    passed in that's going straight into an instance variable, the
    argument can be called 'initialWhatever'.

    Notice that none of those names tell you what the variable is,
    syntactically, but they do tell you what it's for, semantically. To
    me, that's useful information.

    FWIW.
  • On Apr 3, 2008, at 10:45AM, Jens Alfke wrote:

    > Properties and ivars are not the same thing. Properties are
    > shorthand for methods, not variables. A property doesn't have to
    > correspond to any instance variable, or to one with the identical
    > name.

    Excellent point. I did not realize that.

    Often when I feel short on knowledge and experience on a particular
    topic I will look and see what Apple has done.

    In reviewing CALayer.h again I noticed that this class has a ton of
    properties (frame, bounds, position, zPosition, anchorPoint,
    transform, sublayerTransform, contents, contentsRect, opaque,
    contentsGravity, opacity, hidden, masksToBounds, etc.) but no
    explicitly associated ivars that are visible.

    The header looks like this.

        @interface CALayer : NSObject <NSCoding, CAMediaTiming> {
        @private
            struct _CALayerIvars {
                int32_t refcount;
                uint32_t flags;
                uintptr_t parent;
                CFMutableArrayRef sublayers;
                CALayer *mask;
                struct _CALayerState *state;
                struct _CALayerState *previous_state;
                struct _CALayerAnimation *animations;
                struct _CALayerTransaction *slots[3];
        #if defined (__LP64__) && __LP64__
                uint32_t reserved;
        #endif
            } _attr;
        }

    So perhaps any ivar which may be associated with a property are hidden
    in "struct _CALayerState *state". If that is the case they why did
    they hide some of the ivars but not all of them?

    I have also been looking through the WebKit framework and noticed that
    they will hide ALL of the instance variables in another class like this.

        @interface WebView : NSView {
        @private
            WebViewPrivate *_private;
        }

    Can anyone shed light on this practice of hiding ivars? Is it mainly
    something that is being done by the framework developers and generally
    is not applicable to application developers? Why does Apple do this?

    Regards,
    Richard
  • On Apr 5, 2008, at 8:20 PM, Richard Somers wrote:
    > I have also been looking through the WebKit framework and noticed
    > that they will hide ALL of the instance variables in another class
    > like this.
    >
    > @interface WebView : NSView {
    > @private
    > WebViewPrivate *_private;
    > }
    >
    > Can anyone shed light on this practice of hiding ivars? Is it mainly
    > something that is being done by the framework developers and
    > generally is not applicable to application developers? Why does
    > Apple do this?

    Wikipedia can explain it best:
    http://en.wikipedia.org/wiki/Fragile_binary_interface_problem

    -> jp
  • 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 <jens...>
    > 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
  • 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 <jens...> 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

  • On 07/04/2008, at 9:39 AM, 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.

    I think you can be KVC compliant but you have to define setters and
    getters for everything.

    - Chris
  • On Apr 6, 2008, at 7: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.

    Yes and no. KVC doesn't care what the iVar name is if you write KCV
    compliant accessor methods (or use properties.)

    KVC won't work with direct iVar access if you use funny naming
    conventions, but driving the interface by binding directly to iVars
    (instead of public accessors/properties) should be a relatively rare.

    Jim
  • > I just name the all my instance variables  "the_instance_var_" , and
    > the local ones "theLocalVar", this keep me well informed about if X
    > var is instance or local :).
    >

    I do something a little different. For member variables, I use
    camelCase and for for local variables I use_underscores.

    For Objective-C 2.0 properties and KVC compliance as a whole, this has
    worked out quite nicely as I don't have to rename the accessor methods
    or do anything extra.

    @interface MyClass : NSObject
    {
        NSString* firstName;
    }
    @property firstName;
    @end

    @implementation
    @synthesize firstName;
    // definition for show, gc-only
    - (void) setFirstName:(NSString*)first_name
    {
        firstName = first_name;
    }
    @end

    -Eric
  • On Sun, Apr 6, 2008 at 4:39 PM, John Stiles <jstiles...> wrote:
    > You can't be KVC compliant if you use prefixes like m_, so this limits your
    > potential for using things like bindings.

    Of course you can, as long as you define accessors:

    //Pre-Leopard:
    @interface MyObject : NSObject {
      int m_property;
    }

    -(int)property;
    -(void)setProperty:(int)value;
    @end

    @implementation MyObject
    -(int)property { return m_property; }
    -(void)setProperty:(int)value { m_property = value; }
    @end

    Post-Leopard:
    @interface MyObject : NSObject {
      int m_property;
    }
    @property int property;
    @end

    @implementation MyObject
    @synthesize property=m_property;
    @end

    And, in the future when/if you can target 64-bit only, you can avoid
    using named instance variables altogether:

    @interface MyObject : NSObject
    @property int property;
    @end

    @implementation MyObject
    @synthesize property;
    @end

    > 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.

    Though I will concede this point, whenever possible, I like my ivar
    and the property that it backs to have the exact same name.

    >
    >
    > 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 <jens...> 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
    >>>

    >>

    >

    --
    Clark S. Cox III
    <clarkcox3...>
  • On Sun, Apr 6, 2008 at 7:50 PM, Jim Correia <jim.correia...> wrote:
    > On Apr 6, 2008, at 7: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.
    >>
    >
    > Yes and no. KVC doesn't care what the iVar name is if you write KCV
    > compliant accessor methods (or use properties.)
    >
    > KVC won't work with direct iVar access if you use funny naming conventions,
    > but driving the interface by binding directly to iVars (instead of public
    > accessors/properties) should be a relatively rare.

    Of course direct ivar access works with funny naming conventions. The
    keys obviously have to share the funny naming convention, but this is
    just mildly ugly, not any sort of showstopper. For proof, watch
    Interface Builder not grind to a halt when you start prefixing all of
    your IBOutlet names.

    Mike
  • On Apr 6, 2008, at 8:18 PM, Michael Ash wrote:

    > Of course direct ivar access works with funny naming conventions. The
    > keys obviously have to share the funny naming convention, but this is
    > just mildly ugly, not any sort of showstopper. For proof, watch
    > Interface Builder not grind to a halt when you start prefixing all of
    > your IBOutlet names.

    The IB runtime was perhaps a poor example :-), since it doesn't use
    KVC. (Yes, I have filed bugs that it should. I realize there are
    binary compatibility issues.)

    Take, for example, an object with an iVar

      IBOutlet NSView *_containerView;

    and the accessor methods

    - (void)set_containerView:(NSView *)view
    {
      _containerView = view;
    }

    - (void)setContainerView:(NSView *)view
    {
      _containerView = view;
    }

    The first one will actually be used by the IB runtime since it doesn't
    have the same leading underscore magic that KVC does.

    Jim
  • On Sun, Apr 6, 2008 at 7:49 PM, Chris Suter <chris...> wrote:
    > I think you can be KVC compliant but you have to define setters and getters
    > for everything.

    Yes, but I've also experienced the odd issue with the IB unfreezing machinery.

    --Kyle Sluder
  • On Apr 3, 2008, at 9:45 AM, Jens Alfke 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.

    Jens,

    That's an Apple internal coding convention, and it's not recommended
    for anyone else.

    -jcr

    "This is not a book to be tossed aside lightly. Rather, it should be
    hurled with great force." -Dorothy Parker
  • 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 <jens...>
    >>> 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

  • On 6 Apr '08, at 9:17 PM, Scott Andrew wrote:

    > You aren't supposed to EVER use direct ivar acess.  Every document i
    > have ever read regarding ObjectiveC has always said to define
    > acessors.

    Ummm ... for access to another object's instance data, that's true.
    You should avoid the temptation to declare ivars as public and grope
    them directly. But it's fine to access ivars of 'self' by name, and
    most of the Obj-C code I've seen does so.

    > 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.

    You can't do this if your getters or setters are non-trivial. Let's
    say I have a property whose value is computed lazily, a very common
    design pattern:

    - (NSImage*) icon {
    if( ! _icon ) {
      // allocate _icon and draw into it
    }
    return _icon;
    }

    You can't replace "_icon" with "self.icon" because you'd be calling
    the method you're defining, leading to infinite regress and stack
    overflow.

    I guess you could create a separate private property (with ivar)
    called "cachedIcon" and have the -icon getter act on that, but that's
    starting to get silly.

    I'll also re-iterate that calling getters and setters is Extremely
    Expensive compared to directly accessing ivars. As in, something like
    4x as much code at the call-site, and at least 10x as many cycles to
    execute. (Probably more like 20x or 30x if you use the default
    'atomic' style synthesized properties, which do autoreleasing and
    thread synchronization.) It also defeats a number of compiler
    optimizations.

    —Jens
  • This is a very silly remark. Why would they laugh? Even if they did,
    do I care? No. I usually use mSomeVarName or m_someVarName in my
    projects for ivars. I like the 'm', it tells me it's a member. I also
    use s_ for statics and g_ for globals. I come from C++ to Cocoa, so
    what? Whatever convention you use is not important as long as it's
    reasonably consistent and helps you be productive. Telling ivars apart
    from other variables by the use of some naming convention is a very
    good idea, whether you prefix it with 'm' or whatever is irrelevant.

    G.

    On 4 Apr 2008, at 4:58 am, Rob Napier wrote:
    > 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.
  • Too late, I've been doing that since 1990 in C++.

    Seriously, I've yet to run into a problem with it and I have been
    doing it forever.  Just don't be overly general with your variable
    names.  Like I probably wouldn't use _window in a custom view subclass
    or anything.

    -Todd Blanchard

    On Apr 6, 2008, at 6:47 PM, John C. Randolph wrote:

    >
    > On Apr 3, 2008, at 9:45 AM, Jens Alfke 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.
    >
    > Jens,
    >
    > That's an Apple internal coding convention, and it's not recommended
    > for anyone else.
    >
    > -jcr
    >
    >
    >
    >
    > "This is not a book to be tossed aside lightly. Rather, it should be
    > hurled with great force." -Dorothy Parker
  • On Mon, Apr 7, 2008 at 2:37 AM, Todd Blanchard <tblanchard...> wrote:
    > Too late, I've been doing that since 1990 in C++.

    Then I'm sure you're very familiar with the fragile base class
    problem.  Just don't do it.  It's bad form because eventually it will
    break.  And then you'll spend ages in the debugger trying to figure
    out just who assigned to "your" ivar.

    It's quite simply a different language.  Heck, you're *required* to do
    it in C#.  ;-)

    --Kyle Sluder
  • On Apr 5, 2008, at 7:17PM, Quincey Morris wrote:

    > The most common situation where I run into local/instance variable
    > name conflicts is setter methods. If the property and the instance
    > variable are both 'whatever', it makes sense to me to call the
    > setter argument variable 'newWhatever', because that is in fact what
    > it is.

    This agrees with my experience. I have switched to simply using
    "newValue" for the setter argument variable. In other words I
    literally use "newValue" for the setter argument variable for all
    setter methods. Works well so far.

    I also am training myself to pay attention to the color coding XCode 3
    provides to distinguish ivars from local vars.

    Regards,
    Richard
  • On 7 Apr '08, at 1:45 AM, Kyle Sluder wrote:

    > Then I'm sure you're very familiar with the fragile base class
    > problem.  Just don't do it.

    Ivar name conflicts don't have anything to do with the FBC problem,
    not in compiled languages. The FBC problem arises when the size of a
    superclass changes, which changes the offsets of the instance
    variables of subclasses, breaking already-compiled code in subclasses
    that accesses ivars by offset.

    What this means is that, if your superclass adds an ivar, your code is
    broken and has to be recompiled. That's true regardless of what the
    superclass ivar is named. If it does happen to match your name, then
    when you recompile your code you'll get a compile error and can use
    the handy Refactor command to rename your ivar.

    (In practice, Apple will never add ivars to their classes, for exactly
    that reason. That's why they all have a placeholder ivar named
    "_extra" or something like that — if needed, that can be used to point
    to an auxiliary struct.)

    Now, the 64-bit runtime eliminates the FBC by looking up ivar offsets
    dynamically. But IIRC, it doesn't use the names of the ivars when
    doing so (it just looks up the total sizes of instance data of each
    superclass.) So again, name conflicts aren't an issue at runtime.

    > It's bad form because eventually it will
    > break.  And then you'll spend ages in the debugger trying to figure
    > out just who assigned to "your" ivar.

    No, the breakage doesn't occur at runtime, rather at compile time. And
    it results in a simple compile error that's very easy to fix.

    —Jens
  • On Apr 7, 2008, at 9:39 AM, Jens Alfke wrote:

    >
    > On 7 Apr '08, at 1:45 AM, Kyle Sluder wrote:
    >
    >> Then I'm sure you're very familiar with the fragile base class
    >> problem.  Just don't do it.
    >
    > Ivar name conflicts don't have anything to do with the FBC problem,
    > not in compiled languages. The FBC problem arises when the size of a
    > superclass changes, which changes the offsets of the instance
    > variables of subclasses, breaking already-compiled code in
    > subclasses that accesses ivars by offset.
    >
    > What this means is that, if your superclass adds an ivar, your code
    > is broken and has to be recompiled. That's true regardless of what
    > the superclass ivar is named. If it does happen to match your name,
    > then when you recompile your code you'll get a compile error and can
    > use the handy Refactor command to rename your ivar.
    >
    > (In practice, Apple will never add ivars to their classes, for
    > exactly that reason. That's why they all have a placeholder ivar
    > named "_extra" or something like that — if needed, that can be used
    > to point to an auxiliary struct.)

    Right, but by having dummy placeholders, they can later rename
    "_extra" to "_something", and if you have an ivar named "_something"
    there will be problems.  (For that matter, they could also change
    existing ivar names as well).

    > No, the breakage doesn't occur at runtime, rather at compile time.
    > And it results in a simple compile error that's very easy to fix.

    In the case of renaming _extra to _something, no.

    For example, an OS update comes out where a framework has a change
    like this.  Customer upgrades the OS.  There is KVC based access to
    [obj setValue: newValue forKey: @"_something"] (either in your code,
    or in the updated framework - perhaps in NIB loading).  Suddenly there
    is a collision - KVC will change one of them, even though the hard-
    coded access methods will still be grabbing their own respective
    versions.

    So while this isn't exactly the same FBC problem (ivar offsets change
    in already-compiled code) it is very much like it (ivar named access
    changes to a different offset in already compiled code).

    Worse, you won't be able to get the compiler to tell you about this
    error until you get new headers with that change.  But if you are
    compiling against an SDK (which you probably are), you won't see that
    change (since you'll just get the earlier headers).  All you're left
    with is trying to track down why, for example, an outlet is nil after
    loading a NIB that works fine under the last OS version but fails
    under this one (and/or stranger problem than that).

    And, of course, with ObjC 2.0, new ivars can be added, again that can
    conflict with your usage of leading underscores, increasing the chance
    that you'll see this sort of problem.

    Avoiding this sort of hard to track down problems seems well worth the
    price of using something other than a leading underscore on your
    ivars...

    Glenn Andreas                      <gandreas...>
      <http://www.gandreas.com/> wicked fun!
    quadrium | flame : flame fractals & strange attractors : build,
    mutate, evolve, animate
  • On Apr 7, 2008, at 11:12 AM, glenn andreas wrote:

    > Right, but by having dummy placeholders, they can later rename
    > "_extra" to "_something", and if you have an ivar named "_something"
    > there will be problems.  (For that matter, they could also change
    > existing ivar names as well).
    >
    >> No, the breakage doesn't occur at runtime, rather at compile time.
    >> And it results in a simple compile error that's very easy to fix.
    >
    > In the case of renaming _extra to _something, no.
    >
    > For example, an OS update comes out where a framework has a change
    > like this.  Customer upgrades the OS.  There is KVC based access to
    > [obj setValue: newValue forKey: @"_something"] (either in your code,
    > or in the updated framework - perhaps in NIB loading).  Suddenly
    > there is a collision - KVC will change one of them, even though the
    > hard-coded access methods will still be grabbing their own
    > respective versions.

    There is already the possibility of KVC collisions regardless of how
    you name your iVars.

    Consider...

    NSBaseClass, and MyClass derived from it.

    Targetting 10.4, MyClass has an iVar named mImportantProperty (using m
    prefix here only for argument's sake), and accessors -
    setImportantProperty:, -importantProperty.

    10.5 comes along and NSBaseClass gets a private iVar named
    _importantProperty, and the framework code uses KVC to access this
    property (perhaps through the private accessors -
    _setImportantProperty:, -_importantProperty.)

    My code has violated the don't use the _ prefix for your method names
    rule.

    My code hasn't used the don't use the _ prefix on my iVar names rule/
    suggestion/convention.

    Yet, I still have the KVC conflict. (And yes, it will probably be a
    pain in the neck to track down.)

    Jim
  • On Apr 7, 2008, at 10:26 AM, Jim Correia wrote:

    > There is already the possibility of KVC collisions regardless of how
    > you name your iVars.
    >
    > Consider...
    >
    > NSBaseClass, and MyClass derived from it.
    >
    > Targetting 10.4, MyClass has an iVar named mImportantProperty (using
    > m prefix here only for argument's sake), and accessors -
    > setImportantProperty:, -importantProperty.
    >
    > 10.5 comes along and NSBaseClass gets a private iVar named
    > _importantProperty, and the framework code uses KVC to access this
    > property (perhaps through the private accessors -
    > _setImportantProperty:, -_importantProperty.)
    >
    > My code has violated the don't use the _ prefix for your method
    > names rule.
    >
    > My code hasn't used the don't use the _ prefix on my iVar names rule/
    > suggestion/convention.
    >
    > Yet, I still have the KVC conflict. (And yes, it will probably be a
    > pain in the neck to track down.)

    I got burned by this a few years back.  It was extremely difficult to
    track down and I even filed a DTS incident for help with it.  The main
    reason it was difficult was that it was in the implementation of a
    custom control's method:

    - (int)currentValue
    {
        return [[self cell] currentValue];
    }

    Compiler didn't generate any issues.  currentValue did exist on my
    corresponding cell's API, but when Tiger was upon us, currentValue was
    also a method of NSAnimation I believe.  Add onto this the fact that
    [self cell] returns an id, and at runtime, currentValue was sent, but
    to what the runtime thought was an NSAnimation instance.  This really
    trashed memory, but only with my control's instance.  Very strange
    runtime behavior followed.

    Since then, I do the following to never ever collide.  Some may call
    it overkill, but it gives me total piece of mind:

    - all ivars suffixed with _II

    - all methods, including accessors include _II prior to first argument
    (e.g. color_II, setColor_II:, getColor_II:atRow:atColumn:

    - all custom bindings suffixed with _II

    - all keys prefixed with II (e.g. for use with dictionaries, NSCoding
    protocol)

    This was all done in addition to stuff I was already doing previously:
    prefix of II for all class names, structs, enums.

    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
previous month april 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
Go to today