<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 10:37 AM, Kate Stone <span dir="ltr"><<a href="mailto:katherine_stone@apple.com" target="_blank">katherine_stone@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That’s not exactly what I was suggesting.  It’s important to recognize that there is a substantial body of code already written.  It’s impractical to spend time and energy reformatting and renaming everything.  New code should fit in with old, but where it’s already inconsistent there’s an immediate opportunity to start conforming to LLVM’s established style for new contributions.</blockquote>
</div><br>Yes, I'm not advocating for reformatting or restyling existing code. But new code is coming in rapidly, and I think if we know what the eventual end state is, the sooner we switch new code to target that end state the better.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Also, documenting the conventions to be followed within existing code is clearly good to me.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My comment was *only* relevant to figuring out what the end state should be: if the *end state* is LLVM's coding standards plus a bunch of small differences, then I don't think it has gotten the biggest benefit: only having one standard to remember. Until I can forget about any potential differences, I still have to code-switch between the projects, and I suspect LLVM developers will be reluctant to contribute patches to LLDB. I think the correct end state should be an adamant conformance to LLVM's coding standards, and working to change them to improve and address the specific concerns. It is likely that not all of the concerns will be successfully addressed -- this is an area where compromise is inevitable -- but I don't think any of the issues raised should be "deal breakers". The value of a single coding standard vastly outstrips the value of any one specific convention IMO. And I say this precisely because I *despise* many aspects of LLVM's standards and advocate for them strictly due to the value of conformity here.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Anyways, my 2-cents from the LLVM side of things.</div><div class="gmail_extra">-Chandler</div></div>