On Sep 29, 2011, at 9:06 AM, Peter van der Zee wrote:
> What you could do here is require paren-less headers to be single
> lined, on the same line as the `if` keyword, and require a newline
> between the paren-less header and the body. Such newline would signify
> the end of the statement header, much like ASI ("API"? ;). And if you
> want to use a block, you may put the first curly of the block on the
> same line as the paren-less header (or next line if you prefer K&R
> anyways). I'm not so sure if that would fix any of the raised
> objections though.
It would fix the first:
if a + b
(x.y)()
z++
because of no { on same line as the head, but it would not fix the second case
Waldemar showed:
if (a + b)/g > f {f = (a + b)/g}
This case is a paren-full if head followed by an unbraced body, a useless
regexp expression statement. It's valid ES5. The reason this involves
paren-free is that Waldemar showed how refactoring from paren-full to
paren-free mixes with division and a regexp literal to make this paren-full but
undesired outcome.
The ability to write useless expression statements in JS (and C) is a bug.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
