Thread:Manual talk:Coding conventions/JavaScript/Whitespace conventions for control structures should match those for PHP/reply (3)

The only argument I'm willing to push is consistency for exact usage and the reason thereof:
 * Not  in one module and   in another.
 * We don't need to tolerate both variations, because unlike the PHP code base, the JS code base is relatively new and we can easily enforce one variation and stick to it.

The other arguments such as consistency among different operators are harder to document because, as you say,  and   are also operators. So let's not argue that now. If you want you could specify it as follows: "A keyword followed by, it currently tolerates both. See my first point above.

Regarding "more common code conventions", I oppose this because of two reasons:
 * It means we have to read two pages for a language's conventions instead of one.
 * It encourages (and has led to) bad coding habits. Different languages have different syntaxes and internals, despite looking similar. Applying code structure conventions decoupled from the language is dangerous and harder to maintain and use. I've been working on phasing out those "common code conventions". For example, another PHP/JS project I work on preferred placing the curly place on the next line. This is fine in PHP where the distinction is purely stylistic, but in JS there are various cases where this changes the behaviour of the program (usually due to Automatic Semicolon Insertion).

I agree that "More rules" (that is, in order to removing ambiguity) is better. But more variations ("switch cases intended or not intended, if with or without space") or more edge cases ("foo like bar, except when bar is quuxified or when quuxification happens within baz") is not a good thing and serves no purpose what's however other than reducing consistency and asking for problems and conflict resolution. We stick with one and you get used to it.