Question regarding the motivation behind inconsistent space before paren Coding Standard


#1

@jules Can I ask what is the motivation (ie. what benefit it brings) for the two different formats in ‘Always put a space before an open parenthesis! (One exception to this is if you’ve got a pair of empty parentheses)’ in the JUCE Coding Standard? I’m working on a JUCE based contract that has adopted this, and in VS (with VisualAssist) I can get the IDE to automate the formatting for one, or the other, but not both. So I find myself having to manually fix up the opposite case (with VA install I am having to delete the space preceding empty parens).


#2

I’d like to hear this too. Pretty much the only thing I don’t like about JUCE’s code style is this detail. I’m in the same boat, but with JetBrains IDEs. And of course forget about Xcode even supporting any sort of space before parentheses for function calls. At this point I’ve forced myself to muscle memory back to whatever got autocompleted to re-format, but it’s just a weird style to begin with I’ve never seen anywhere else.


#3

Adding one more to the pile, I never understood this. To me, the parentheses are part of the function.


#4

Me neither. It’s just such a waste of space. Badum tsss


#5

I heard JUCE spells parentheses with a ‘u’ :thinking:


#6

So you’ve never read any English text that contains parentheses? It’d look a bit odd(to say the least)if we didn’t leave a space around parentheses when writing.

And in programming, we follow all the other written-English space practices, e.g. with commas, semi-colons, quotes, arithmetic operators.

However, an empty pair of parentheses isn’t something you ever see in written English, so there’s no rule we could follow, and to my eyes it looks very odd to see it adrift from the word to which it is associated, hence the lack of space in that case.

Hope that helps to answer the question!


#7

Sadly it answers it perfectly. lol. I had hoped for something that made less sense, and could be argued with. How do you handle it when writing code?


#8

Never really noticed it as a problem… As an Xcode user, I guess I’ve got used to the fact that most of the code I type will get indented wrongly (and by that I mean actually incorrectly rather than just not being to my own taste), and I spend a lot of time going back to correct things, so having to also occasionally go back and add a space has never really been a burden.

(And TBH whenever I use Xcode’s auto-complete to insert a function call, it also pastes those stupid special placeholder objects for the parameters, which you then have to faff around trying to select and delete, and that takes much longer than it does to just go back to pop a space in there!)


#9

wellWeAlsoDontWriteSentencesAsCamelCasedText, so I’m not entirely sure I agree with the analogy since function calls don’t really read like typical English in the first place. I’d be much more inclined to follow the style of the C++ standard (and everyone else), which is pretty roughly JUCE’s style but with the parentheses against the function.

To me it makes sense in my brain because the arguments are a part of the function call, so having the arguments as part of theWholeFunctionCall(just, makesSense) because it’s one contiguous expression rather than two separate ideas (as is usual with in-sentence parentheses).

Going back to the fact that no IDE supports this odd styling, it makes me hope that one day maybe there will be a revolution a la placing the namespace juce scope in every file to increase IDE compatibility and productivity for users. I’m sure it would be a bit of a pain for JUCE devs to adjust muscle memory, but it’s arguably a lot easier than making the rest of the world adjust if they’re trying to write JUCE-style code…


#10

I’d say most peoples brains, belonging to coders or not, will instantaneously recognize a division between

theWholeFunctionCall(just,

and

makesSense)

Because of the white space.

To determine where the function name ends and the parameter list begins, your brain will have to scan the whole chunk of letters searching for a (.

Thats why separating the parameter list from the function name makes more sense than concatenating the function name with the first parameter.


#11

I don’t think anyone ever suggested that juce users are supposed to use the juce coding style in their own code!

We publish our style rules because people have requested it, and hopefully people find it interesting (certainly the non-aesthetic rules are recommended).

But don’t get the impression that we dictate how our users write their own code! We like our style, and it’s designed to be as clear to read as possible, but whether or not you want to adopt it is entirely up to you. If you have some kind of visceral hatred of it, you could always run astyle or clang-tidy over it and make it look however you like!


#12

All good points. I suppose I have forced myself to adopt the JUCE style when writing JUCE-related code in hopes one day my code will be just as nice to read :stuck_out_tongue: