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

[Chandler Carruth]

On Mon, Nov 22, 2010 at 9:36 PM, Zhanyong Wan (λx.x x) <wan at google.com>wrote:

> On Mon, Nov 22, 2010 at 9:30 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > Sorry, this seems to have not followed the thread, but here was my
> comment:
> >
> http://codereview.appspot.com/3264041/diff/1/docs/CodingStandards.html#newcode801
> > docs/CodingStandards.html:801: camel case (e.g. <tt>TextFileReader</tt>
> > and <tt>isLValue</tt>).
> > I would really prefer some stylistic difference between variables and
> > types/functions. This is mostly a problem (for me) with local variables,
> > where having some signifier of the locality helps me in reading it.
>
> Agreed.  That's why types start with upper-case while variables start
> with lower-case in my proposal.
>

This however leaves no distinction between functions and variables. I
suppose this isn't a terrible compromise because of the ()s, but I would
like it best to have a different style for each.


> I chose to start function names with lower-case, but don't feel
> strongly about it.  If people prefer them to start with upper-case,
> fine by me.
>

I wonder which is better for function names. I don't mind collision in style
between function and type names as much as between variable names and other
names, but that's just my personal preference.


> I think camelCase works as well as underscore_separated for variable
> names, and the former is much more common in the existing code.
> That's why I picked it.  I could go with underscore_separated were we
> starting from scratch.
>

This is a good point regarding consistency. I'm curious if this is a good
time for more dramatic changes, and if so whether we want to consider having
distinctions for all of the above, but if not, I'm not opposed to the
proposed change. I see it as a definite improvement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101122/aab24a1f/attachment.html>