[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