> > 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 <[email protected]> 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 <[email protected]> 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. > > >
