On Tue, Jan 22, 2013 at 12:36 PM, Nick Kledzik <kledzik at apple.com>
wrote:
> On Jan 20, 2013, at 10:18 PM, Chandler Carruth wrote:
>
> Sorry, I wasn't trying to suggest anything vague, but rather refer to
my
> previous (perhaps ill founded) understanding about the expected path
> forward for LLD. Anyways, I'll explain in a bit more detail so we can
talk
> about the concrete issue.
>
> My concrete hope is that LLD migrates toward the coding standards that are
> shared by both the core LLVM libraries and Clang. The specifics are
> documented here: http://llvm.org/docs/CodingStandards.html
>
> The golden rule at the top of that coding standard specifically says to
> not make sweeping style changes like you suggest.
>
Currently, LLD is relatively small, and so a sweeping style change might
not be unreasonable. Or it might be unreasonable. In my first email, I
acknowledge that if preferred we could do this on a per-file bases as
someone comes to the file to work with it.
I'm much more interested in establishing what the direction should be than
in worrying with the exact mechanism for getting ther.
>
> Some specific items that jump out at me as areas of noticeable divergence:
> - Constructors' initializer lists
>
> I don't know what you mean by this. There is nothing in LLVM coding
> standards about constructors (other than don't have static
constructors).
>
Yes, but there is a desire for consistency and uniformity throughout the
code. There are 13 constructors with initializer lists formatted using the
leading-comma style LLD uses heavily:
Foo::Foo(...)
: member(...)
, member2(...)
, member3(...) {
}
That is in a very small minority. I'd like to not have different formats
for such things as it waste's developers time writing them. clang-format
does a very nice job already of formatting initializer lists, and it is
reasonable consistent with LLVM and Clang's codebases, so personally I
would just use it's format. I don't really care what the format is, as
long
as it is consistent across LLVM and LLD. Deviations here just add noise to
patch review and code reading, especially as code migrates back and forth
between common libraries and LLD specific code.
> All other things being equal, sure, consistency is nice. But lld is
> already very consistent with LLVM. The only places where it diverges is to
> make the code better: the use of C++11, and the sane naming of variables.
>
When I looked at a few header files, I found inconsistencies in them
quickly:
- Resolver.h: inconsistently aligned variable names in declaration
sequences (lines 180-184, 188-198)
- File.h: The naming of enumerations of the kinds of things.
(lld::File::Kind)
- InputFiles.h: indentation and comma placement for parameters. (lines
54-58)
But I don't really care how many or where. The point is whether consistency
across LLVM and LLD is the desired end state. If so, then when folks are
touching these files they can reformat into a consistent state. If not,
then folks have to learn to read, write, review, and maintain two divergent
styles of code. The latter is what I would like to avoid.
There may be a company culture difference here. At Apple our source
is> organized into hundreds of independently built "projects". Each
project
> team determines their own coding style because they are the ones that have
> to live in their source base. Over time there is a cross fertilization of
> coding styles as engineers move between teams. My understanding is the
> Google, because of the centralized build infrastructure is much more rigid
> about coding style.
>
I care very little about Google's coding style. I care much more about the
open source community, and the collection of projects under the LLVM
umbrella being readily accessible to developers. I care about developers
hacking on Clang, LLVM, and LLD interchangeably and with a minimum learning
curve when hopping projects. I care about ensuring that common data
structures and abstractions developed in Clang or LLD (or other projects)
being consolidated and shared in the LLVM core libraries without increased
inconsistency.
> I've had many discussions with lld contributors and 99% of the time it
is
> about coming to understand the atom model and just where code should go to
> achieve some result. Coding style is not an issue.
>
Well, our experiences here differ. I'm talking mostly to potential lld
contributors, and they often are turned off by coding style. I'm not
claiming they're right to be turned off by something small like this, but
as an open source project it seems like the goal should be to remove any
and all barriers to contributions possible.
> But none of this argues that the LLVM style is The Right Style. If there
> are ways to improve the coding conventions with LLVM and Clang, we should
> absolutely do that. The projects remain small enough that if you can show a
> convention which is superior, we can easily adopt it for new code going
> forward, and as tools such as clang-format (and its future brethren) become
> more common we can even swiftly adopt new conventions across all of the
> code.
>
>
> Ok, you've poked me enough. I'll be the one to say "the
emperor has no
> clothes". The LLVM convention for naming variables is poor.
You'd be
> hard pressed to find any other C++ coding conventions that start variables
> with a uppercase letter. When the lld project started, I wrote up this
> attachment to describe why lld was using a better variable naming
> convention.
>
You may or may not know this, but I actually argued against the LLVM
convention for naming variables when Chris was formalizing some parts of
the coding standards. Over time, I have ceased to really care, and I think
Chris was entirely correct that ultimately the naming convention for
variables shouldn't matter. If they are well named, everything will be
clear.
My desire is for lld to be a little corner where we try out this
new> convention.
>
A different naming convention is one of the most disruptive things to have
change between two code bases. It will cause people to habitually write
code one way, realize they are submitting to the other repository, and have
to mechanically go and rename all their variables. While I personally like
your naming convention slightly better than LLVM's, and a few other
conventions slightly better than yours, I really don't care.
I think we (and by we, I mean Chris in his role as BDFL of the LLVM coding
standards) should pick a naming convention, and stick to it. If Chris wants
to switch LLVM's guidelines for new code going forward to match yours,
I'm
fine with that. If he wants to make up a third convention, I'm fine with
it. As long as I can train my fingers to write in one pattern when working
with the various LLVM projects, and forget about everything else I'm happy.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130122/0a28b00d/attachment.html>