llvm dev - Dec 2010 - [LLVMdev] [cfe-dev] draft rule for naming types/functions/variables

Thanks for the comments, Chris!  Glad that we are making progress.

I'll make most of the edits you suggested later today.  Before that,
there are a couple of high-level points I'd like to go over with you.

1. I totally agree that the biggest benefit of a naming convention is
uniform APIs.  On the other hand, an inconsistent local naming style
hurts the productivity of contributors and can lead to bugs by causing
confusion.  I'm fine with local variables having short names when
their scope is limited (say, fits within one screen) or their role is
obvious (like 'i' for an iterator), but I do find the context
switching annoying when I have to adjust for the different styles as I
move to different parts of the codebase.  Just something for you to
consider.

2. (more important than #1) I'd like to understand the reason behind
your preference for UpperCase names for ivars.  Is it just a personal
preference or is there a more profound reason?  So far, I've heard
that some people like lowerCase ivars (clear distinction from types,
etc), and some people don't think that helps much.  However, I'm yet
to hear why UpperCase ivars are considered *better* than lowerCase, so
I'm curious.

Thanks.

-- 
Zhanyong

On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote:
> Thanks for the comments, Chris!  Glad that we are making progress.
> 
> I'll make most of the edits you suggested later today.  Before that,
> there are a couple of high-level points I'd like to go over with you.
> 
> 1. I totally agree that the biggest benefit of a naming convention is
> uniform APIs.  On the other hand, an inconsistent local naming style
> hurts the productivity of contributors and can lead to bugs by causing
> confusion.  I'm fine with local variables having short names when
> their scope is limited (say, fits within one screen) or their role is
> obvious (like 'i' for an iterator), but I do find the context
> switching annoying when I have to adjust for the different styles as I
> move to different parts of the codebase.  Just something for you to
> consider.
Sure, but it is also a cleanly separable policy decision that we can make after
the more important half of the project happens :).  Lets do the more important
part first, then come back to this.
> 2. (more important than #1) I'd like to understand the reason behind
> your preference for UpperCase names for ivars.  Is it just a personal
> preference or is there a more profound reason?  So far, I've heard
> that some people like lowerCase ivars (clear distinction from types,
> etc), and some people don't think that helps much.  However, I'm
yet
> to hear why UpperCase ivars are considered *better* than lowerCase, so
> I'm curious.
The only reason I suggested UpperCase for ivars is that *by far* the most ivars
are named like that in the current codebase.  If you're reading into case
for distinctions, one way to look at it is that lowerCase is for methods,
everything else is types or data.  I also think that public ivar names are much
less important than the other cases, particularly given how few there are.

-Chris

On Tue, Nov 30, 2010 at 5:07 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote:
>
>> Thanks for the comments, Chris!  Glad that we are making progress.
>>
>> I'll make most of the edits you suggested later today.  Before
that,
>> there are a couple of high-level points I'd like to go over with
you.
>>
>> 1. I totally agree that the biggest benefit of a naming convention is
>> uniform APIs.  On the other hand, an inconsistent local naming style
>> hurts the productivity of contributors and can lead to bugs by causing
>> confusion.  I'm fine with local variables having short names when
>> their scope is limited (say, fits within one screen) or their role is
>> obvious (like 'i' for an iterator), but I do find the context
>> switching annoying when I have to adjust for the different styles as I
>> move to different parts of the codebase.  Just something for you to
>> consider.
>
> Sure, but it is also a cleanly separable policy decision that we can make
after the more important half of the project happens :).  Lets do the more
important part first, then come back to this.
I'll buy that. ;-)
>> 2. (more important than #1) I'd like to understand the reason
behind
>> your preference for UpperCase names for ivars.  Is it just a personal
>> preference or is there a more profound reason?  So far, I've heard
>> that some people like lowerCase ivars (clear distinction from types,
>> etc), and some people don't think that helps much.  However,
I'm yet
>> to hear why UpperCase ivars are considered *better* than lowerCase, so
>> I'm curious.
>
> The only reason I suggested UpperCase for ivars is that *by far* the most
ivars are named like that in the current codebase.  If you're reading into
case for distinctions, one way to look at it is that lowerCase is for methods,
everything else is types or data.  I also think that public ivar names are much
less important than the other cases, particularly given how few there are.
All right.  That sounds reasonable.  Thanks for clarifying.

-- 
Zhanyong