[LLVMdev] lld coding style
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
> 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...
More information about the llvm-dev