On 02/17/2014 04:59 AM, Manu wrote:
On 17 February 2014 03:14, Timon Gehr <[email protected]
...
Of course, I'd just write the above as:
int difficulty = e.note.note.between(60,108) ? (e.note.note-60)/12 : -1;
Yes yes, very clever.
I can't agree.
Obviously it's an example and could come in any shape or form.
Obviously. Hence, no need to point this out.
Personally, I also wouldn't do that anyway; basic readability has
definitely been lost.
...
IMO quite the opposite is true. And everything around it will tend to
become simpler to follow at a glance as well.
The default case is a total waste, since -1 should just be
assigned when
initialising the variable above.
...
How is the compiler supposed to know? It might be a logic error for
e.note.note to be out of range.
Then I should have used an invariant or something actually designed for
catching values out of range.
It's not the compilers fault I made a logic error. I could make a logic
error literally anywhere in my code. Why force an annoying rule
It's not inherent to the rule.
to maybe sometimes catch exactly one case
Well, it is also not the kind of error I make, but it still documents
intention. It would be easy to sloppily omit default: assert(0) without
this rule without actually affecting correct code, but I wouldn't warmly
recommend this practice.
(while making other competing cases where a logic error isn't present more
annoying).
That's roughly the dynamic typing argument. Obviously 'switch' is quite
lame (being lame seems to be an inherent quality of statement-based
syntax), but the requirement to explicitly handle the default case
instead of implicitly skipping it is not why.
