JUCE Coding Standard: Parentheses

[DustVoice]

First off I want to say that I really appreciate the post of the JUCE coding standards, which I have mostly already been doing anyway or adapted over time. The only thing I find weird is the parentheses formatting.
If you follow the JUCE coding standards, you should write parentheses without content directly after the word, without a space, but with content, they should have a space before them:

ClassOne classOne = new ClassOne();
ClassTwo classTwo = new ClassTwo ("Some argument");

so far so good. I’m not gonna argue that this looks bad. But here come some edge cases:

classTwoUniquePtr.reset (new ClassTwo ("Some argument"));

looks a little bit weird to me. It gets more extreme with this:

classTwoUniquePtr = makeUnique<ClassTwo> ("Some argument");

I somehow find that very weird looking… Also if you have a chain of methods:

Desktop::getInstance().getComponent (1);

just looks wrong to me! Also every IDE I have encountered up until this point can’t handle this. Its either space before all parentheses blocks, or no space! There is no handling for parentheses with content, and without, also it defaults to no space before them.

I would love to hear some opinions on this. Have you adapted this coding standard in your own code? (Not arguing about the JUCE code base, but rather individual projects using most of the coding standard.) This is the one thing I haven’t adapted to my own code base yet and it kinda bothers me as I’m not sure if there is a good reason to do so … Can someone using this give me some reasons why I should too / should not use this?

[DustVoice]

Also how should I do array initialization according to the standard?

vector<int> intArr = {1, 2, 3, 4};

or

vector<int> intArr2 = { 1, 2, 3, 4 };

?

[mcmartin]

You might want to read this thread: Question regarding the motivation behind inconsistent space before paren Coding Standard

[DustVoice]

Thanks I already read that. I just wanted to know if anyone has really adopted it in their own code base and I should think about doing so too, or if the majority of people is ignoring this.

[daniel]

I use it for consistency too. But I am planning to ignore all that and run @reuk’s clang-format automatically before checking in, just like I call Projucer --trim-whitelpace --lf Source already.

It is just like formatting using word vs. laTeX…

Automatic JUCE-like code formatting with clang-format

When writing new code that relies on JUCE, it’s nice to follow the style conventions from the JUCE coding standards so that everything looks consistent, and to reduce cognitive overhead when jumping between JUCE files and project files. I’m not a big fan of manually typing spaces to align function arguments and things, so one of my favourite tools is clang-format. I can just write whatever I want, without thinking about formatting, and it tidies up after me. This is great, because now I can jus…

[RustyPine]

I don’t put spaces before parenthesis in my own code. I agree looks odd to me in some instances and less snug & compact Also I use AppCode and as you said its all or nothing for auto formatting.

[reFX]

I use spaces before my parentheses regardless if their content is empty or not. The first reason is that my IDE does that automatically (MSVC + Visual Assist) already and the second reason is that it looks more consistent throughout the source.

It doesn’t look odd to me at all. It gives my mind some breathing room. Easier on the eyes with some whitespace here and there. Mushing everything too close together makes for overly long strings of characters that are harder to parse for the human brain.

The reason to not do it for empty parentheses seems very arbitrary to me. Because the English language doesn’t use empty parentheses? So suddenly a RULE, just set up a sentence earlier, contradicts itself? Essentially creating an exception where none was needed? Making it harder on IDE/Editors and the human? Why?

[reuk]

After using this for a few months, it starts to look pretty natural - but then the same could be said of most standards. I have a PR open against clang-format which implements this formatting rule, which is currently undergoing review. I’m hopeful that this will be accepted in the near future.

I’m a big fan of a workflow where I write in a very freeform way, and then let clang-format tidy up after me. It feels a lot more frictionless than doing the formatting as you go along.

Re: brace formatting, the style I use is spaces everywhere for non-empty braces (I have a clang-format rule for this too).

That means, nested empty braces look like this {{}}, but braces with contents get spaces either side of the braces like so { { "key", "value" }, { "anotherKey", "anotherValue" } }. If I was typing that manually, I’d get fed up of adding all that extra spacing - but, if you have a tool to enforce it automatically, I think it’s worth it because the result does look nicer.