<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 20, 2013, at 10:18 PM, Chandler Carruth wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div>
<div style=""><br></div><div style="">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: <a href="http://llvm.org/docs/CodingStandards.html">http://llvm.org/docs/CodingStandards.html</a></div>
<div style=""><br></div></div></div></div></blockquote><div>The golden rule at the top of that coding standard specifically says to not make sweeping style changes like you suggest.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">Some specific items that jump out at me as areas of noticeable divergence:</div><div style="">- Constructors' initializer lists</div></div></div></div></blockquote><div>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).</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">- Naming patterns (for locals, members, functions, arguments, etc…)</div></div></div></div></blockquote><div>lld has the same naming for types, functions, and methods as LLVM. It is just the naming of variables that has been improved. </div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div style="">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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote>
<div><br></div><div style="">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.</div>
<div style=""><br></div><div style="">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*.</div></div></div></div></blockquote><div>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. </div><div><br></div><div>Also, there are many scopes of consistency. The LLVM convention for variables names is inconsistent with most C++ code in existence.</div><div><br></div><div>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. </div><br><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div style="">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.</div>
<div style=""><br></div><div style="">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.</div></div></div></div></blockquote><div>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. </div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">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.</div>
</div></div></div>
</blockquote><br></div><div>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. </div><div><br></div><div></div></body></html>