<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Please do forward that clang-format file when you have it put together. I would love to have access to that.<div class=""><br class=""></div><div class=""><div class="">
<div class="">Sean</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Aug 19, 2014, at 11:06 AM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Definitely agree with you on this. I have no plans to go fixup old code, and I don't think others should either. And if we see a change go through that does attempt to fix up old code, we should block it. <div class="">
<br class=""></div><div class="">That said, I'm working on a clang-format file that will automate this formatting for us (or at least, for me, should nobody else choose to use it), and I plan to run it against all my changelists before submitting them. Note that this only reformats lines that have already been touched by the CL, so there's no risk of formatting-only changes making it in.</div>
</div><div class="gmail_extra"><br class=""><br class=""><div class="gmail_quote">On Tue, Aug 19, 2014 at 11:00 AM, Sean Callanan <span dir="ltr" class=""><<a href="mailto:scallanan@apple.com" target="_blank" class="">scallanan@apple.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">One point about this discussion, by the way.<div class=""><br class=""></div><div class="">While I support adherence to a consistent style for new/changed code, this should in no way be taken as support for going through and fixing indentation/style on old code.</div>
<div class="">We have internal branches that become hell to merge when e.g. spacing has been altered subtly, or brace depth is changed…</div><div class="">If we all do our part to clean the parts we’re touching, then I think that will be enough to keep LLDB clean. </div>
<span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div></font></span><div class=""><span class="HOEnZb"><font color="#888888" class=""><div class="">
<div class="">Sean</div>
</div>
<br class=""></font></span><div class=""><blockquote type="cite" class=""><div class=""><div class="">On Aug 19, 2014, at 10:16 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div><br class=""></div><div class="">
<div class=""><div class="h5"><div dir="ltr" class="">I brought this up in a thread on lldb-commits, but since it is of more general interest, I want to make a thread here as well.<div class=""><br class=""></div><div class="">Can we have clear direction on LLDB coding style? Ideally in the form of an update to <a href="http://lldb.llvm.org/" target="_blank" class="">lldb.llvm.org</a>, but as that might require a little more effort, even some details in a response to this thread would be a help. Some things I've deduced from looking at the code, and other things I'm not so sure about, because of inconsistencies in the code or just no clear rule.</div>
<div class=""><br class=""></div><div class="">Indentation width: 4</div><div class="">Column limit: 140 (does this apply to comments too? Most function-declaration comments seem to wrap at 80)</div><div class="">Brace style: Allman</div><div class=""> if (foo)</div><div class="">
{</div><div class=""> // code here</div><div class=""> }</div><div class=""><br class=""></div><div class="">Break after function return type: Always, only on declarations, only on definitions, only in headers, or never?</div><div class=""><br class=""></div><div class="">Space before function parentheses: When?</div>
<div class=""><br class=""></div><div class="">Indent case labels inside switch: A or B below?</div><div class=""> switch (foo)</div><div class=""> {</div><div class=""> case A:</div><div class=""> case B:</div><div class=""> }</div><div class=""><br class=""></div><div class="">Indent braces inside of a case: A or B below?</div>
<div class=""> switch (foo)</div><div class=""> {</div><div class=""> case A:</div><div class=""> {</div><div class=""> }</div><div class=""> case B:</div><div class=""> {</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class="">Any other rules I should be cognizant of?</div>
</div></div></div><div class="">
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" class="">lldb-dev@cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br class="">
</div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>