Relaxing the requirement to put a space in empty {}s?

[Jeffrey Yasskin]

`git cl format` currently turns:

virtual void func() { }

into

virtual void func() {}

which check-webkit-style complains about at
https://code.google.com/p/chromium/codesearch/#chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/style/checkers/cpp.py&l=2082.

In b/14651985 (sorry, non-Googlers) Daniel asks that Blink allow
either style in order to av complexity to clang-format.

What does blink-dev think?

Thanks,
Jeffrey

[TAMURA, Kent]

IMO we should remove this style rule, and align with Chromium.  { + space + } has no advantage.

--

TAMURA Kent
Software Engineer, Google

[Peter Kasting]

I would remove this style rule and not mandate either style -- both seem readable and IMO authors should be able to do either.

PK

[Levi Weintraub]

I'm happy with both like Peter. If removing this rule gets us the ability to have an arbitrary amount of space, I'm not a fan. I'd prefer not to have only the Chromium style if that means moving code around can get the style checker to complain.

[Dana Jansens]

On Tue, Jun 16, 2015 at 12:30 AM, Levi Weintraub <le...@chromium.org> wrote:

I'm happy with both like Peter. If removing this rule gets us the ability to have an arbitrary amount of space, I'm not a fan. I'd prefer not to have only the Chromium style if that means moving code around can get the style checker to complain.

FWIW if you run git cl format on your change that moves code around you don't have to think about it.

[Joshua Bell]

ISTM we should:

(1) Rewrite the Blink C++ style guide [1] to be just deltas from the Chromium[2] (and transitively, Google[3]) C++ style guide.

(2) Strive, over time, to reduce the number of deltas.

I assume #1 is non-controversial? We can likely do without the Objective-C rules now. A quick glance suggests about half the rules are obsolete or redundant with Chromium (...) style. What I don't know is if these rules match style checking tools that don't themselves "fall back" to the Chromium (...) style.

#2 is, of course, more opinionated, and is intended to codify that when an option presents itself we lean towards reducing the number of special cases (e.g. FIXME->TODO, { } -> {}, etc), not that we clang-rewrite accidentally the whole thing.

[1] https://www.chromium.org/blink/coding-style

[2] https://www.chromium.org/developers/coding-style

[3] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html