[LLVMdev] LLD vs LLVM coding style...

[Chandler Carruth]

On Sun, Jan 20, 2013 at 8:35 PM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote:
> > We're looking more at doing some serious hacking on LLD, and I'd like to
> avoid doing lots of work in the codebase only to change the style around
> later.
> >
> > My understanding was that LLD was always intended to be a fully
> integrated LLVM project much like Clang, with a shared coding standard to
> go with the shared support libraries. Can we start that migration? I'm
> really opposed to having folks learn two styles of development, only to
> turn around and unlearn one shortly thereafter.
>
> Before suggesting a massive and vague changes across someone else's code
> base, perhaps you should start with specific issues you see.  And why you
> think one way is better than another way.
>

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

Some specific items that jump out at me as areas of noticeable divergence:
- Constructors' initializer lists
- Naming patterns (for locals, members, functions, arguments, etc...)

My more general desire is for LLD's codebase to strive for consistency with
LLVM's and Clang's. This, of course, is a two-way street. Several
conventions have started with the Clang codebase and migrated to be more
widely used within LLVM.


> The LLVM family of projects have a range of coding conventions.  libc++,
> lldb, and LLVM core have different styles.  That is a good thing.  Coding
> conventions should not be ruled with an iron fist.  There needs to be some
> room for innovation  and experimentation so that the conventions can evolve
> and improve.


First, libc++ is quite special. It shares no code with LLVM's core
libraries, and has many conventions which out of necessity diverge in order
to both co-exist cleanly with the C++ standard's specified conventions, and
the necessary protection against colliding tokens with preprocessor macros.

LLVM and Clang have extremely similar styles, and I think that is a good
thing. I think LLDB would benefit also from being consistent. Now, my
argument is not that of an iron fist, or that the LLVM style is "better" in
some abstract sense. Instead my argument is driven almost exclusively by
*consistency*.

It is a simple reality that to work with either LLD or Clang, a programmer
must work extensively with the core LLVM libraries. As a consequence,
having divergent styles between them creates a significant burden on
developers moving back and forth across that boundary. For new developers,
they must learn two different styles, and train themselves to both read and
write code proficiently in both styles. For existing developers who have
worked on LLVM in the past, it is a barrier to contributing to LLD which
seems bad for building and growing the open source community.

So in essence, my primary motivation is to have less divergence between two
codebases that are deeply connected and to make it easier to grow the LLD
community. In fact, I'm trying to bring myself and other LLVM developers
into the LLD community, and this is one issue that regularly slows down
that process.


However, there is a second reason to pick the specific LLVM coding
convention. We are building really awesome tools[1], which as you suggest
in your email to Sean, allow the tools to ensure the code follows a
particular convention, and the programmers to focus on algorithms, design,
and other more important matters. These tools are being developed initially
to support the existing conventions in LLVM and Clang, and it would be a
large (and of questionable utility) effort to add support for another
convention as well. In essence, the desire for tools *also* advocates for
the projects being consistent.

[1] http://clang.llvm.org/docs/ClangTools.html#clang-format


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130120/ed74d945/attachment.html>