On Jun 3, 2015, at 1:59 PM, Uli Kusterer wrote:

> On 03 Jun 2015, at 19:09, Alex Zavatone <z...@mac.com> wrote:
>> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
>> 
>>> So you're not supposed to use the underscore convention even for your 
>>> private ivars, as Apple could add secret stuff to NSObject or any other 
>>> base class you'd collide with.
>>> 
>>> -- Uli
>> 
>> So, how are we expected to tell the private/public/ivar/property difference 
>> between all these variables we have to look at all day in an easy, clear and 
>> straightforward manner that doesn't require unnecessary thinking?
> 
> I've never had a problem telling that difference, so I can't answer that 
> question for you. If an object is complex enough that this becomes an issue, 
> I'd probably split it up into several objects so it becomes easier and more 
> obvious to grasp.
> 
> -- Uli

Well, I wonder if starting private properties with a p as in pSomeAwesomeThing 
would be a decent-enough convention to start, because then an ivar for a 
private property would be _pSomeAwesomeThing.

This would leave public properties without any lowercase p (followed by a 
capital letter that starts the next word) and the ivar would be the same, but 
just starting with the _.

That would give us:

Public property:                        labelString
Public property's ivar:                 _labelString
Private property:                       pLabelString
Private property's ivar:        _pLabelString


Does this seem to be a decent enough and not unweildy convention?  While it 
wouldn't show any difference between a local or a parameter, it would certainly 
clarify the scope of these 4 cases.

Is this enough, or should we also take into effect locals and parameters?  For 
locals, we could use my as a prefix since they would be local to the method, 
but that could end up as a PITA.

Also, how would this conflict with the recommended is prefix for booleans, if 
at all?

Thanks much, man.

Alex Zavatone
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to