On 4/13/18 4:49 PM, Nathan Froyd wrote:
On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote:
Those changes I assume were generated with clang-format / clang-format-diff
using the "Mozilla" coding style, so I'd rather ask people to agree in
whether we prefer that style or other in order to change that if needed.

Would people agree to use:

  , mIsRootDefined { false }

Instead of:

  , mIsRootDefined{ false }

What's people's opinion on that? Would people be fine with a more general
"spaces around braces" rule? I can't think of a case right now where I
personally wouldn't prefer it.

If we are going to have brace-initialization intermixed with
list-initialization (i.e. parentheses) in our codebase, I think we
should prefer no space prior to the brace, for consistency.

Hmm, consistency with parenthesis I guess, but not with other things that use braces, like conditionals or other kind of declarations (where we use a space after the paren, for example), or lambdas where we use `mutable {`, etc.

Also, I guess per that argument we should use `mIsRootDefined{false}` instead of `mIsRootDefined{ false }`.

If we are going to switch wholesale (which would be a big job!)... I'd
probably say "no space", just on "that's the way we've always done it"
grounds, but can be convinced otherwise.

Though this is a good point though, I've only found a couple of them with spaces:

$ rg ' m[A-Z][A-Za-z]* \{ ' | wc -l



  $ rg ' m[A-Z][A-Za-z]*\{ ' | wc -l

Though that could be an artifact of clang-format in the directories we run it.

I agree with bz on disallowing braces in constructor init lists.

I'd be ok with that I guess, though it's more common each time? Also, is there any case where you could use braces but not parenthesis? (I'm not a C++ expert in this regard).

Also, we should probably state that consistency is preferred (I assume we
generally agree on that), so in this case braces probably weren't even
needed, or everything should've switched to them.


Finally, while I'm here, regarding default member initialization, what's

   uint32_t* mFoo = nullptr;


   uint32_t* mFoo { nullptr };

I lean towards the former here.  I think the former is more common in
the code I've seen, but apparently the latter is "preferred C++" or

I think the former is ok, but wouldn't work for stuff like:

  Atomic<int32_t*> mFoo = nullptr;


    Atomic<int32_t*> mFoo { nullptr };

does work.

 -- Emilio
dev-platform mailing list

Reply via email to