Just three completely undocumented syntax examples...
Mapping values in an object:
{a, b} = c
Backslash to continue lines:
a = long_variable_name \
+ other_long variable name
Switch statements without a parameter:
switch
when function_that_needs_to_return_true
stuff
But the bigger problem is just having no idea how things will parse. For example, this works:
a = b +
c
But this doesn't:
a = b
+ c
And then this works:
switch a
when b, c, d
e()
But this doesn't (a multi-line form you might want to use if the variable names were really long):
switch a
when b,
c,
d
e()
And this doesn't:
switch a
when b
when c
when d
e()
After trial-and-error, you discover it has to be this, with a seemingly random backslashes:
switch a
when b, \
c, \
d
e()
I could go on and on -- but you get the point. The whole language is only discoverable via trial and error. None of this is documented. (Apologies for taking up so much vertical space of the comments!!)
Basically, if statements are that long, the code should be refactored. This makes it easier to read and reduces the opportunity for bugs. That pattern is one of the main reasons I like CoffeeScript.
Parent's point is that he wants better documentation, and possibly better consistency, on things like breaking lines; breaking lines was just an example to illustrate the larger point.
Sorry, but that's completely bizarre. The whole point of a switch statement is to be able to test a single value against a list of single values, or groups of single values.
The supposed "correct way" you support moves the values outside of the switch statement, which completely destroys reading comprehension of the code. It explodes the number of lines of code necessary. This isn't refactoring, it's complete code obfuscation.
It also makes the switch statement itself completely superfluous, since you might as well just do a series of if / else if's, and save an extra line of code. I mean, the whole point of switch is to pass a parameter and compare it against values.
Sorry, what's completely bizarre is having variable names which push the 80 character limit. That doesn't help reading comprehension at all.
For instance, look at the recently posted Matches.js [1] -- there are many reasons to factor out the test case when the test case is unusual. 80 character test cases are unusual.
80 character test cases (variables or otherwise) should be factored out. The readability and purpose of the method is compromised if you have 5 groups of 30 constants. Factor the groups out into individual maintainable functions. Then there is one function per case, and an overview of the entire switch can be seen in a few rows rather than several pages.
What are you talking about? My particular use case that led to all this was just translating a simple, clean, elegant JavaScript switch like the following. It's ideal, really, in terms of readability:
switch (operation_code) {
case SUGGEST_ACTION:
...
break;
case PERFORM_ACTION_PREAUTHORIZE:
case PERFORM_ACTION_AUTHORIZE:
case PERFORM_ACTION_POSTAUTHORIZE:
...
break;
case DELETE_ACTION_REVERSIBLE:
case DELETE_ACTION_IRREVERSIBLE:
case DELETE_ACTION_NOT_PREAUTHORIZED:
case DELETE_ACTION_PREAUTHORIZED:
...
break;
case UNDO_ACTION:
...
break;
(5 more groups of 30 more constants...)
}
It's not variable names that push an 80 character limit. It's about translating groups of shorter constants, that taken together go over 80 lines, and which have similar prefixes, so they look very nice listed vertically, and make it very clear where their differences and similarities are.
I stand by my point: telling people that, in CoffeeScript, it's proper to "refactor" this into a switch statement with no parameter and creating entire new functions, is bizarre.
Hey, that's a really good use case for multi-line cases. Not exactly the fallthrough behavior of the JavaScript example you posted ... but a good reason to want linebreaks in your list of values to match. You should open a ticket suggesting a syntax improvement for it.
2) This has to do with the unary plus operator more than just cs - since +varname is an expression, it treats it as such. Fair complaint - I've never run into that. Also, this works just fine if you put the plus on the end of the first line:
a = long_var_name +
hey_another_var
3) When would you use those?
4+5) Are cases of the unary operator in 2)
6-10) Sure, this is limiting if you want to write switch statements like that.
I feel that your coding style is different, or that you're listing edge cases to be contrarian. Coffeescript has a much smaller range of syntax deviations but that's part of what allows it to be so brief and clean.
His 1-3 were complaining about undocumented syntax, and the rest about the actual syntax itself. Not that your response is wrong, just that might help you understand what he was saying.
Line-breaks end statements in CoffeeScript, this is the same as
a = b; +c
That should be pretty apparent. Your other examples are mostly abuses, and you'll not find "documentation on forbidden syntax" for any other language either.
Javascript or Coffeescript shouldn't ever have lines ending with a backslash.
I'm not so sure the addition one isn't actually also applicable to javascript automatic semicolon insertion. The google js style guide (publicly available) says that all lines must end in an infix operator, opening bracket or semicolon to always avoid accidental semicolon insertion.
Though the switch one seems surprising (read: a flaw) since it is usually safe to end a line with a comma in vanilla js.
Basically, you can almost always remove the semicolons without trouble and more often then not problems occur from semicolons not being inserted then from them being inserted in unexpected positions. The "returning an object literal" case is the only common case where a semicolon is mischeviously inserted.
I wasn't trying to express a strong stance on the issue, just pointing out what the Google's js style guide says, the + on the next line wouldn't be allowed there (nor .)
Mapping values in an object:
Backslash to continue lines: Switch statements without a parameter: But the bigger problem is just having no idea how things will parse. For example, this works: But this doesn't: And then this works: But this doesn't (a multi-line form you might want to use if the variable names were really long): And this doesn't: After trial-and-error, you discover it has to be this, with a seemingly random backslashes: I could go on and on -- but you get the point. The whole language is only discoverable via trial and error. None of this is documented. (Apologies for taking up so much vertical space of the comments!!)