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

Chris Lattner clattner at apple.com
Tue Nov 30 17:07:43 PST 2010


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



More information about the llvm-dev mailing list