Please do forward that clang-format file when you have it put together. I would love to have access to that.
Sean > On Aug 19, 2014, at 11:06 AM, Zachary Turner <ztur...@google.com> wrote: > > 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. > > 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. > > > On Tue, Aug 19, 2014 at 11:00 AM, Sean Callanan <scalla...@apple.com > <mailto:scalla...@apple.com>> wrote: > One point about this discussion, by the way. > > 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. > We have internal branches that become hell to merge when e.g. spacing has > been altered subtly, or brace depth is changed… > If we all do our part to clean the parts we’re touching, then I think that > will be enough to keep LLDB clean. > > Sean > >> On Aug 19, 2014, at 10:16 AM, Zachary Turner <ztur...@google.com >> <mailto:ztur...@google.com>> wrote: >> >> 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. >> >> Can we have clear direction on LLDB coding style? Ideally in the form of an >> update to lldb.llvm.org <http://lldb.llvm.org/>, 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. >> >> Indentation width: 4 >> Column limit: 140 (does this apply to comments too? Most >> function-declaration comments seem to wrap at 80) >> Brace style: Allman >> if (foo) >> { >> // code here >> } >> >> Break after function return type: Always, only on declarations, only on >> definitions, only in headers, or never? >> >> Space before function parentheses: When? >> >> Indent case labels inside switch: A or B below? >> switch (foo) >> { >> case A: >> case B: >> } >> >> Indent braces inside of a case: A or B below? >> switch (foo) >> { >> case A: >> { >> } >> case B: >> { >> } >> } >> >> Any other rules I should be cognizant of? >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev> > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
