JavaScript guidelines: Space after if

[erosman]

I came across JavaScript guidelines which states:

There should be no space between a control statement keyword, function, or loop keyword and its opening parenthesis (e.g. if() { ... }, function myFunc() { ... }, for(...) { ... }).

However as far as if () vs if().... (as well as for())

• if() is hardly a common practice anywhere
• Code examples on MDN use if ()
• Firefox code also uses if () (e.g. WebRTCParent.jsm)

Is if() really the recommended practice?

Also ... 8 - White Space

8.2 Blank Spaces

Blank spaces should be used in the following circumstances:

• A keyword followed by a parenthesis should be separated by a space.

[hamishwillee]

I personally much prefer if (condition) { to if(condition); perhaps I'm the person injecting the incorrect examples :-0. I'm not sure it matters as long as we are consistent. Ideally we might fix this up with prettify.

@wbamberg Any opinion on this? Do we ever automate prettify to fix this stuff?

[wbamberg]

Yeah, I also prefer if (condition) { (and I believe I said so at the time this guideline was adopted).

But more than preferring one style or another, I would love to have Prettier automate this for us, per something like mdn/content#9565 - for a PR that took me 5 minutes to write I'm impressed with how clean it seems to be. But I've been concentrating on finishing off the Markdown conversion and haven't put a lot of time into moving that forward. One obvious problem raised in that PR is what to do about code that's demonstrating bad practices.

There's also the distinction between running Prettier once, and getting everything consistent, which is relatively simple, and having the machinery to ensure everything stays consistent (https://github.com/mdn/content/discussions/9353) which looks more complicated to me.

[hamishwillee]

One obvious problem raised in that PR is what to do about code that's demonstrating bad practices.

Shouldn't that all have the example-bad marker against it? One would hope that prettier might be trained to ignore that.

Do you think we can reopen the discussion on this particular case of if? I suspect far more cases are the way we like it than matching the guide.

A few thoughts

• The discussion is worth waiting on you finishing markdown.
• I think this should definitely be a yari option to make it easy do anytime.
• It would be even better if there was some way to preview the change without having to commit the change to github.
• We're a long way from discussing the option of running this in CI. I have my doubts that would ever be "safe" but we could work towards it. The precondition for that would be being able to run a flaw checker and trust prettier to auto-fix the result.
• Rather you than me :-)

[erosman]

Just a note to say that the topic is not limited to if, and should apply to all JavaScript keywords followed by a parenthesis

ref: JavaScript Reserved Words
Is there such a doc on MDN? 🤔

For example:

if (...)
do...while (...)
for (...)
for each...in (...)
for...in (...)
for...of (...)
for await...of (...)
while (...)
switch (...)
catch (...)

Functions/methods followed by parenthesis should not have any space before parenthesis.
Are there any other cases? 🤔

[erosman]

Another reference to consider:
Google JavaScript Style Guide

4.6.2 Horizontal whitespace
Use of horizontal whitespace depends on location, and falls into three broad categories: leading (at the start of a line), trailing (at the end of a line), and internal. Leading whitespace (i.e., indentation) is addressed elsewhere. Trailing whitespace is forbidden.

Beyond where required by the language or other style rules, and apart from literals, comments, and JSDoc, a single internal ASCII space also appears in the following places only.

1. Separating any reserved word (such as if, for, or catch) except for function and super, from an open parenthesis (() that follows it on that line.

It might be prudent to update JavaScript guidelines.

[hamishwillee]

I had a chat to @ddbeck about this. In summary he agrees with @wbamberg above

• we should use prettier to enforce a coding standard.
• It doesn't matter exactly what that coding standard is because there will always be someone else who has a differing opinion. That is the benefit of prettier - you get what you get and you don't get upset (as my kindergarden teacher used to say :-) ).
• Obviously we will have to find workarounds for problems like example-bad so that some things get skipped, but those are surmountable problems.

Anyway, the upshot is that he doesn't think we should be trying to keep the guidelines updated or fixing non-compliant cases - because when the resource eventually comes to put prettier in place, this will all become moot.

[hamishwillee]

@wbamberg Hope I didn't misrepresent Daniel :-). I do see this though as a kind of approval to go ahead with a requirement against yari.

[ddbeck]

There's a couple threads here that have called out for my attention so I'll lay out my position here (cc: @hamishwillee and @wbamberg, specifically):

• We should work toward adopting Prettier to format code automatically and comprehensively. The first step toward that would be to adopt a Prettier config and check it in the repository. The process would culminate with full automated enforcement with CI.
• Until that process is complete, we should cut down the JavaScript style guidelines to replace anything that Prettier could format with text saying, more or less, do whatever Prettier would do or configure your editor to do this.
• In the mean time, we should reject any PRs that make style-only changes or any proposals to change the code style guidelines beyond what's already been described in this comment.

If y'all are onboard with this approach, there's a few natural issues that I could open to track the work, based on the text above.

[wbamberg]

I'm totally on board with this. I don't mind so much what we do in the interim but I'm very in favour of having Prettier formatting the code. The interactive examples use ESLint and we might at some point want to consider that too, although it's likely to be more work to set up and more intrusive, since it goes beyond just formatting of course.

[ddbeck]

ESLint would be a good follow on to Prettier! We could do things like enforce some of the things you're modernizing (e.g., require let and const in likely places).

[ddbeck]

I've created mdn/content#10402 and a number of related issues. In the process, I found that Prettier has an option to insert pragmas, which might help us enable Prettier incrementally. See mdn/content#10411 for further reading.

[teoli2003]

The more coherent we are, the better. I have no strong feelings about the conventions. So I think we should do it.