[lldb-dev] LLDB Coding Style
Sean Callanan
scallanan at apple.com
Tue Aug 19 10:55:24 PDT 2014
AFAIK we don’t have a column limit. I certainly don’t enforce one on myself, though I break lines when they don’t “look nice” anymore.
I try to stick with a separator between the function name and the open parenthesis when declaring a function/method but not when calling one. I try to add spaces after “for”, “if”, “while”, “switch,” etc.
In general I prefer to wrap even single line for/else blocks in braces, but in code where pre-existing logic doesn’t have braces, I’ll follow suit. (This is particularly prevalent when using logs: if(log) log->Printf(“…”);)
As far as case statements:
switch (foo) {
case A:
{
}
}
is what I’d prefer. It really bugs me when there isn’t a clean staircase of close-braces.
For instance variables of a class, I try to align them on a 4-space tab, and the * in a pointer or & in a reference sticks with the name and extends to the left of the alignment tab, e.g.:
A m_a
B *m_b
Enrico’s point about naming applies here, too: m_ should mean an instance variable and g_ should mean a global (or class-level static).
In general, if I use a std::vector or std::map in a class, I’ll typedef it so that making iterators etc. doesn’t look horrid. Unless the expression on the right hand side has its type explicitly named (typically in a cast, but I’d accept a constructor too) I do not use the “auto” keyword.
Sean
> On Aug 19, 2014, at 10:16 AM, Zachary Turner <zturner at 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 at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140819/2e76075e/attachment.html>
More information about the lldb-dev
mailing list