[LLVMdev] lld coding style

Chandler Carruth chandlerc at google.com
Wed Oct 8 19:31:05 PDT 2014

On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <kledzik at apple.com> wrote:

> The lld conventions for ivars is a leading underscore followed by a
> lowercase letter.  The reserved identifiers are a leading underscore
> followed by an uppercase letter.  There is no conflict.

And I didn't say that there was. They are *close*. Too close. People make
mistakes and get it wrong.

> On the other hand the LLVM conventions prevents the use of the -Wshadow
> which catches real bugs.

I don't think this is inherently true. I would have no trouble working to
fix existing shadows in LLVM and turn on the warning.

> However, I care much less about the particular naming convention than that
> we have a consistent naming convention. And changing LLD to LLVM's style
> and then later changing LLVM's style (and all the subprojects) will not
> appreciably increase the amount of churn required to the project as a
> whole. So I don't think we should hold up progress in the pursuit of
> perfection here.
> So you are saying, let’s make lld’s code worse and maybe someday make
> lld’s and llvm’s code better.

That's a very LLD-centric way of looking at it.

I'm saying let's make the entire LLVM project better by being more
consistent between subprojects. Maybe someday we can make that consistent
state also a better state. But avoiding consistency until that arrives is,
in my opinion, blocking progress in the name of perfection. I would rather
incremental progress.

> Why not hold off on changing lld until the broader naming convention is
> decided, then change lld to that?  lld has been using these conventions for
> years.  What is the rush?

The rush is that more and more people would *like* to start contributing to
LLD. But they have to continually try to remember to deal with the
inconsistencies between the two codebases. That wastes peoples time and
discourages new contributors.

>  Besides, if you strip the distinctive name from ivars, it will be hard to
> automatically add that back.

The primary hope of changing all of LLVM's naming conventions is the ready
availability of Clang-based tools to manage the migration. Such tools don't
need distinctive names, they *know* which names are member variables.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141008/15a6871c/attachment.html>

More information about the llvm-dev mailing list