Skip navigation.
 
mlRe: Coding Standards For Objective C
FROM : Ricky Sharp
DATE : Wed Nov 24 22:41:10 2004

On Nov 24, 2004, at 2:32 PM, Scott Stevenson wrote:

> On Nov 24, 2004, at 11:58 AM, Ricky Sharp wrote:
>

>> e.g.:    float mShadowOffset;
>> 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.

> [...]

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

>
> I rarely see it in Code, and Apple's guidelines don't mention it at
> all. I think the main problem with something like this from Cocoa's
> persepective is that something like "m" is pretty terse.


I agree.  I'll be adopting the guidelines for ivars and not prefix them.

> I think I read a recommendation in Apple's docs somewhere that local
> vars can have the prefix "my" if the name is otherwise the same as an
> ivar. You can also "the". The point is to make it readable, and "m"
> isn't ideal for that. Same with "pz" and such.


Thanks for pointing out that recommendation; I think I'll adopt it.

>> 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]];
>> }

>
> I personally think this is wasteful, but it really depends on how how
> often -foo is called and the context. Sometimes someAttribute won't be
> the same from one line to the next.


Agreed.


On Nov 24, 2004, at 3:27 PM, Sherm Pendley wrote:

> On Nov 24, 2004, at 2:58 PM, Ricky Sharp wrote:
>

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

>
> In general, it's a good idea to use accessors any time you need to do
> more than a simple assignment.
>
> One example when you have an ivar that's an object type. Generally,
> when you assign it a new value, you retain the new value and
> (auto)release the old value. Consistently using an accessor in that
> case will isolate your memory management into one place, making it
> less likely to have retain/release bugs, and easier to debug if it
> does.
>
> Another example is threading. If you're using mutexes to coordinate
> access to an ivar among multiple threads, it's not a bad idea to
> isolate all of that mutex-related code into accessor methods.


Good points.

Thanks Sherm and Scott for your replies; definitely helps me pick a
direction to take.

___________________________________________________________
Ricky A. Sharp        mailto:<email_removed>
Instant Interactive(tm)  http://www.instantinteractive.com

Related mailsAuthorDate
mlCoding Standards For Objective C Sanoop Nov 24, 07:17
mlRe: Coding Standards For Objective C Wade Tregaskis Nov 24, 07:25
mlRe: Coding Standards For Objective C j o a r Nov 24, 07:32
mlRe: Coding Standards For Objective C Sanoop Nov 24, 09:37
mlRe: Coding Standards For Objective C Shawn Erickson Nov 24, 18:03
mlRe: Coding Standards For Objective C Ricky Sharp Nov 24, 20:58
mlRe: Coding Standards For Objective C Scott Stevenson Nov 24, 21:32
mlRe: Coding Standards For Objective C Sherm Pendley Nov 24, 22:27
mlRe: Coding Standards For Objective C Ricky Sharp Nov 24, 22:41
mlRe: Coding Standards For Objective C M. Uli Kusterer Nov 25, 21:47
mlRe: Coding Standards For Objective C Andrew Farmer Nov 26, 23:00