• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Coding Standards For Objective C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coding Standards For Objective C


  • Subject: Re: Coding Standards For Objective C
  • From: Ricky Sharp <email@hidden>
  • Date: Wed, 24 Nov 2004 13:58:03 -0600

On Wednesday, November 24, 2004, at 11:04AM, Shawn Erickson <email@hidden> wrote:

>
>On Nov 23, 2004, at 10:32 PM, j o a r wrote:
>
>> <http://www.cocoadevcentral.com/articles/000082.php>
>
>Scott you are putting out some nice articles!
>
>Great looking, clear, and to the point.

I agree.

However, I'm still struggling a bit with the naming of variables.  I've come from years of C/C++ development to include using MetroWerks PowerPlant.  Over time, I came up with the following convention:

(1) all instance variables (members) are prefixed with 'm'

e.g.:    float mShadowOffset;

(2) all parameters are prefixed with in, out, or io to denote usage

e.g.:    int foo (int inAddend, int inAugend, int& outSum)

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


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.

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.

If I do change my code, one thing that becomes a pain is the whole local variable named the same as an ivar.

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.  The naming of that local variable is sometimes a pain.

For example:

@interface MyClass : NSObject
{
    float someAttribute;
}
- (float)someAttribute;
- (void)foo;
@end

@implementation MyClass
- (float)someAttribute
{
    return someAttribute;
}

- (void)foo
{
    int theAttribute = [self someAttribute];

    [self someMethod:theAttribute];
    [self anotherMethod:theAttribute];
}

How do folks typically name local variables so as not to trip up with the ivar name?  Prefix with 'a', 'the', etc.?

Also, for foo, should I really be calling the accessor everywhere rather than having a local?

- (void)foo
{
    [self someMethod:[self someAttribute]];
    [self anotherMethod:[self someAttribute]];
}

Of course this is _not_ valid when you need to guarantee that the attribute must not change (e.g. it could be the case where someMethod may alter the value of someAttribute).  Note that such a thing could be brought up as bad design.  But here I'm just trying to illustrate a point.

Thanks,

--
Rick Sharp
Instant Interactive(tm)
 _______________________________________________
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

  • Follow-Ups:
    • Re: Coding Standards For Objective C
      • From: "M. Uli Kusterer" <email@hidden>
    • Re: Coding Standards For Objective C
      • From: Sherm Pendley <email@hidden>
    • Re: Coding Standards For Objective C
      • From: Scott Stevenson <email@hidden>
References: 
 >Coding Standards For Objective C (From: "Sanoop" <email@hidden>)
 >Re: Coding Standards For Objective C (From: j o a r <email@hidden>)
 >Re: Coding Standards For Objective C (From: Shawn Erickson <email@hidden>)

  • Prev by Date: Re: Split slider control?
  • Next by Date: Re: Coding Standards For Objective C
  • Previous by thread: Re: Coding Standards For Objective C
  • Next by thread: Re: Coding Standards For Objective C
  • Index(es):
    • Date
    • Thread