[LLVMdev] RFC: variable names

[Chandler Carruth]

On Mon, Oct 13, 2014 at 3:28 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> > If we are going to change how we name variables, I very much want them to
> > not collide with either type names or function names. My suggestion
> would be
> > "lower_case" names.
> >
> > This also happens to be the vastly most common pattern across all C++
> coding
> > styles and C-based language coding styles I have seen.
>
> STL has "lower_case" functions, and exposes far fewer variables.


STL also has "lower_case" types. The STL naming convention is very simple:
lower_case everywhere. I'm actually fine with this, and even understand
some of the reasons it makes sense for the STL (what is a type? or a
function? they're really interchangeable in the STL in many cases).

But I also really appreciate why most coding standards I have seen
advocated try to use distinguished naming conventions for these things to
make it easier to tell at a glance what things are what. And I suspect this
kind of optimization for skimming and rapid comprehension is the correct
way for LLVM to structure its style. We just don't do enough generic
programming to make it terribly important to make names consistent between
functions, variables, and types.

I can't really recall which of myFunc/my_var or my_func/myVar I've seen
> more elsewhere though.


I think using underscores for function names would cause a moderate to
extreme degree of chaos in the APIs of LLVM. It doesn't really seem worth
considering IMO, but if others really want to advocate for it, carry on.

My position is that trading one set of collisions for another set of
collisions is a poor tradeoff. I would much rather trade for no collisions.

I actually have a particular allergy to member variable names and function
names having similar styles:

bool x = i->isMyConditionTrue;

Did I mean to write 'isMyConditionTrue()'? Or 'bool &x =
I->isMyConditionTrue'? Or something else? I have no idea. Warnings and
other things can help reduce the likelihood of this becoming a live bug,
but it still makes the code harder to read IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/69b50209/attachment.html>