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> 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 > 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
