[lldb-dev] Style guide and clang-format.

[Zachary Turner]

Great to hear!  I will make this change to the style guide in the coming
days if nobody objects further.

In the meantime, I would love for you guys (and anyone else for that
matter) to try out clang-format.  It would be great to work out any kinks
in the existing rules file.  For cases where there's a compelling enough
reason, if clang-format doesn't support what we need, we can get it added.
But for most things I think it should already either be correct in the
existing rules file, or be fixable with a few tweaks and no modifications
to clang-format itself.

On Mon Feb 09 2015 at 1:40:33 PM Kate Stone <katherine_stone at apple.com>
wrote:

> On Feb 9, 2015, at 12:45 PM, Zachary Turner <zturner at google.com> wrote:
>
> I was trying to give you the benefit of the doubt :)  TBH I'd be even
> happier if we just use the LLVM rule consistently.  But it's often easier
> for people to do this slowly.  From your original response though it sounds
> like you might be fine just removing this rule and going with the LLVM
> style.  If so, I'm definitely all for that.
>
>
> This is completely consistent with what I’ve advocated for the team here:
> we deviate from the established LLVM convention for new code only in ways
> that are well-documented, consistently followed in the established code
> base, and for which we have a compelling rationale.  I think sticking with
> LLVM style here makes the most sense.
>
> Of course there will always be the temptation to make sure that minimal
> additions to existing files don’t stand out as egregiously different.
> Hopefully some common sense can be applied in these cases.
>
> Kate Stone k8stone at apple.com
>  Xcode Runtime Analysis Tools
>
> If it makes you feel any better, I'm not crazy about some of their rules
> either.  And actually they aren't even crazy about some of their rules.
> But it does help with consistency and readability for people who work
> across all of the codebases, and I think that kind of cross-project
> pollination is really helpful for the individual projects, as well as the
> community as a whole.
>
> On Mon Feb 09 2015 at 12:06:25 PM <jingham at apple.com> wrote:
>
>>
>> > On Feb 9, 2015, at 11:59 AM, Zachary Turner <zturner at google.com> wrote:
>> >
>> >
>> >
>> > On Mon Feb 09 2015 at 11:56:44 AM <jingham at apple.com> wrote:
>> >
>> > I actually do think that having the space between the complex visual
>> noise of the argument list and the function name makes it easier to detect
>> functions when scanning code, which was why we did it this way to start.
>> That and from years of working on FSF code, Jason & I were used to it.  It
>> was a hard-and-fast rule for FSF code, but then for C++ this sort of thing:
>> >
>> > target.GetProcess ().GetSelectedThread ().GetStackFrameAtIndex (0)
>> >
>> > just looks stupid.  So we don't use it there.  I have a Quixotic desire
>> to have some not hard-and-fast rules in the coding conventions, and rather
>> to decide based on what looks good, because "I'm a free man, dammit!".
>> >
>> > That's fine, and that's why I'm proposing just removing it from the
>> style guide.  Because leaving it in, and saying "We do this, but
>> actually... not everyone does, but you can do it if you want!" is kind of
>> redundant and unnecessary.  Unfortunately clang-format, being a tool, does
>> have hard and fast rules.  So it seems like we can just say "do it if you
>> want, but clang-format will remove it for you, and hopefully you use
>> clang-format (because it has many other benefits as well)"
>>
>> That's a little problematic, because it's easier if the lldb style guide
>> falls back to the llvm style guide on all the issues it doesn't specify.
>> So if we leave the line out, then that should mean use the llvm rule.
>>
>> Jim
>>
>>
>>  _______________________________________________
> 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/20150209/9357ef19/attachment.html>