[LLVMdev] lld coding style

[Chandler Carruth]

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>