2011/4/19 Bob Nystrom <[email protected]>: > On Mon, Apr 18, 2011 at 7:46 PM, Mike Samuel <[email protected]> wrote: >> var x = "foo" >> + "bar" > > That's true. I believe in languages that default to treating newlines as > significant, the style is to put a binary operator at the end of the line > and not at the beginning of the next one. Given the above code, I don't > think it's even clear what the programmer intended. We can only assume they > wanted the binary operator because unary plus has no side-effect. > A change like I'm describing here would definitely affect existing code. > Leading commas are another place where this would need attention:
This seems a serious problem to me. There is a large population of EcmaScript developers who develop in Java on the server, and ES on the client. Widely accepted java style guidelines mandate line-breaking with the operator the on-next line. http://www.oracle.com/technetwork/java/codeconventions-136091.html#248 " * Break after a comma. * Break before an operator. ... longName1 = longName2 * (longName3 + longName4 - longName5) + 4 * longname6; // PREFER " is not contradictory because comma is not an operator in Java. The second is not as widely followed as the first, but is still fairly widely followed among java programmers. I think there are a large number of programmers who, because of those java style guidelines and the way ASI works, write javascript breaking before operators except for comma operators. http://www.google.com/codesearch?q=%5Cx20%5Cx20%5Cx20%5B%2B-%5D%5B^%2B-%5D+lang%3Ajavascript shows numerous examples. If true, this is not just a matter of code backwards compatibility, but of porting programmers. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
