mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Park <mcyp...@gmail.com>
Subject Re: Mesos Style Guideline Adjustments
Date Fri, 31 Jul 2015 01:25:17 GMT
Oops, sorry I was so excited that this could just solve the issue that I
forgot to answer your question.

In general, the clang-format strives to adopt widely used styles, which I'm
not sure if we would be considered widely used. Aside from that, another
concern was that it could take a while for our style proposals to make it
upstream and for it to be useful.

On Thu, Jul 30, 2015, 6:12 PM Michael Park <mcypark@gmail.com> wrote:

> Is it worth adding our own style?
>
>
>
> I noticed other have (LLVM, Google, Chromium, Mozilla, WebKit.). How
>> hard is it?
>
>
> I was just looking into this again and *Mozilla* was added as the newest
> *BreakBeforeBraces* style. It breaks before braces on enum, function, and
> record definitions (struct, class, union). I think we can actually use that
> one and be done with it. Having looked through the codebase, we wrap the
> braces for *enum* for about half of the cases. It would be about 35
> instances that we have to fix from what I can see in our codebase. What do
> you think?
>
> On Thu, Jul 30, 2015 at 5:14 PM Benjamin Mahler <benjamin.mahler@gmail.com>
> wrote:
>
>> Is it worth adding our own style?
>>
>> I noticed other have (LLVM, Google, Chromium, Mozilla, WebKit.). How hard
>> is it?
>>
>> On Thu, Jul 30, 2015 at 4:23 PM, Michael Park <mcypark@gmail.com> wrote:
>>
>> > There are a few syntactical Mesos style guidelines that I would like to
>> > propose to drop. They are:
>> >
>> >    1. Open braces for namespace should not be wrapped.
>> >    *NOTE*: The Google style guide does not wrap the brace after
>> > *namespace*,
>> >    and the Mesos style guide does not mention a rule at all. But it is
>> >    consistent throughout the codebase.
>> >    2. Overloaded operators should be padded with spaces.
>> >    3. Comments should be wrapped at 70 characters.
>> >
>> > The main motivation is that as a community we would like to reduce the
>> > discrepancy between what *clang-format* produces. This is a dual
>> effort, as
>> > we work on improving *clang-format* to support some of our style which
>> is
>> > popular in the C++ community as well. Wrapping the function arguments to
>> > avoid "jaggedness" for example is a feature request which is being
>> tracked
>> > at: https://llvm.org/bugs/show_bug.cgi?id=23422
>> >
>> > Going forward, the proposal is to update all of the instances of (1) and
>> > (2) at once. For (3), we can simply relax the constraint from 70 to 80
>> > without touching the existing comments.
>> >
>> > Does anyone have any strong opinions about dropping any of the 3 rules
>> > above?
>> >
>> > Thanks,
>> >
>> > MPark.
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message