5 ms·

Am I really the only one who finds it actually a wee bit harder to read when "eyeing" through a lot of code ? It might look nicer, but you read it like "do this

by nolok 15y ago

Am I really the only one who finds it actually a wee bit harder to read when "eyeing" through a lot of code ? It might look nicer, but you read it like "do this, ah no cancel it if that" forcing you to rollback in your head.

skeptical 15y ago
I always had that opinion about that feature too. It's present in quite a few languages. I think people like to point out that they can do things that you can't in other languages and end up going ridiculous paths. As if the real power of a programming language could be inferred from it's syntax. Don't get me wrong, I like coffee script and I find the tool linked on this thread quite useful, but come on... rewriting all the 'ifs' as 'unless' jut because you can looks pointless and silly to me. Just my opinion.
TrevorBurnham 15y ago
It looks weird at first, but it's great when used like so: return x unless err return y if condition ... return z Keeping all of your "return"s at the start of the line makes it much easier to see, at a glance, what the possible return values of your function are. (And, of course, when you see a "return" in the middle of your function, you know there must be a condition attached.)
- baddox 15y ago
  The traditional alternative also puts your returns at the beginnings of lines. It just uses a lot more lines. if (!err) { return x; } if (condition) { return y; } ...
  - ww520 15y ago
    Not if you do if (!err) return x; if (condition) return y;
Groxx 15y ago
I tend to like it if the left-hand-side is overwhelmingly the default code-path, or to keep all assignments aligned (ones with caveats then stick out like a sore thumb). How do you feel then about things like this? variable = if something val else another_val end (insert your personal indentation choice, of course)
- aaronblohowiak 15y ago
  This does not cause any "backtracking" when tracing the code execution with the gray interpreter.
  - Groxx 15y ago
    >'with the gray interpreter' sorry, ya lost me there. Are you referring to a language interpreter? In that case, which one? The only difference I can see for interpreters is that it necessitates parsing the entire line before acting, which all but the most highly-tuned (and designed for this purpose) interpreted-languages probably already do.
    - deleted 15y ago
      [deleted]
    - damncabbage 15y ago
      I'm guessing that he's referring to his brain.
      - Groxx 15y ago
        Ahahaha, of course, that makes sense. Thanks, I may have to wake up the hamster in mine :)

by nolok 15y ago

skeptical 15y ago

I always had that opinion about that feature too. It's present in quite a few languages. I think people like to point out that they can do things that you can't in other languages and end up going ridiculous paths. As if the real power of a programming language could be inferred from it's syntax. Don't get me wrong, I like coffee script and I find the tool linked on this thread quite useful, but come on... rewriting all the 'ifs' as 'unless' jut because you can looks pointless and silly to me. Just my opinion.

TrevorBurnham 15y ago

It looks weird at first, but it's great when used like so: return x unless err return y if condition ... return z Keeping all of your "return"s at the start of the line makes it much easier to see, at a glance, what the possible return values of your function are. (And, of course, when you see a "return" in the middle of your function, you know there must be a condition attached.)

baddox 15y ago
The traditional alternative also puts your returns at the beginnings of lines. It just uses a lot more lines. if (!err) { return x; } if (condition) { return y; } ...
- ww520 15y ago
  Not if you do if (!err) return x; if (condition) return y;

Groxx 15y ago

I tend to like it if the left-hand-side is overwhelmingly the default code-path, or to keep all assignments aligned (ones with caveats then stick out like a sore thumb). How do you feel then about things like this? variable = if something val else another_val end (insert your personal indentation choice, of course)

aaronblohowiak 15y ago
This does not cause any "backtracking" when tracing the code execution with the gray interpreter.
- Groxx 15y ago
  >'with the gray interpreter' sorry, ya lost me there. Are you referring to a language interpreter? In that case, which one? The only difference I can see for interpreters is that it necessitates parsing the entire line before acting, which all but the most highly-tuned (and designed for this purpose) interpreted-languages probably already do.
  - deleted 15y ago
    [deleted]
  - damncabbage 15y ago
    I'm guessing that he's referring to his brain.
    - Groxx 15y ago
      Ahahaha, of course, that makes sense. Thanks, I may have to wake up the hamster in mine :)