<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">+1 to the general idea. I don't hack on LLD, though, so not sure how much weight my opinion has here.<div><br></div><div>-Jim</div><div><br><div><div>On Jan 20, 2013, at 10:18 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Sun, Jan 20, 2013 at 8:35 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank" class="cremed">kledzik@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<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"><div><br>
On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote:<br>
> 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.<br>
><br>
> 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.<br>
<br>
</div>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.<br></blockquote><div>
<br></div><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 style="">Some specific items that jump out at me as areas of noticeable divergence:</div><div style="">- Constructors' initializer lists</div><div style="">- Naming patterns (for locals, members, functions, arguments, etc...)</div>
<div style=""><br></div><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 style=""><br></div><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 style=""><br></div><div style=""><br></div><div style="">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.</div>
<div style=""><br></div><div style="">[1] <a href="http://clang.llvm.org/docs/ClangTools.html#clang-format">http://clang.llvm.org/docs/ClangTools.html#clang-format</a></div><div style=""><br></div><div style=""><br></div><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>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></div></body></html>