That's great news Kate! The other thing I would encourage is that, once
guidelines are formalized and published, that we try to encourage everyone
to get in the habit of running clang-format against their CLs before
submitting. No point in having a coding standard if isn't followed. Daniel
Jasper posted a script earlier in the thread that should make this easy.
Perhaps some bumps will arise early on, but I think everyone is interested
enough in having LLDB adopt clang-format that someone will be amenable to
addressing any problems with clang-format that should arise.
On Wed, Aug 20, 2014 at 10:43 AM, Kate Stone <katherine_st...@apple.com>
wrote:
> I’ve been largely observing the thread, but just so not all the
> conversations happen internally, I should point out that I’m encouraging
> the team to go ahead and formalize coding standards so we can publish them
> to the community. I’ll strongly discourage ambiguity and guidelines that
> involve picking one style or another based on “what looks better.” We
> should make it clear where we expect conformance from submissions. Where
> our existing code base is inconsistent I strongly encourage hewing to
> established LLVM convention. We shouldn’t be arbitrarily different, and
> where we do differ we should be able to describe the specific rationale (as
> I’m sure Greg will gladly do when it comes to line length and naming
> conventions.)
>
> I should probably also take a moment to introduce myself! I manage
> Apple’s LLDB efforts for Chris as well as the performance tools in Xcode.
> Since taking on the team I’ve been largely focused on our Swift efforts,
> but I do endeavor to keep up with what’s going on in the broader LLDB
> community.
>
> Kate Stone k8st...@apple.com
> Xcode Runtime Analysis Tools
>
> 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, 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
