81–90 of 326 posts
I find inheriting code riddled with witty logic puzzles distasteful, so prefer my predecessor to have written Python, which constrained them from crafting too many.
Some people want a project to be a series of cryptic crosswords. For them perl/ruby/C.
When I write perl/ruby/C, I restrain myself from filling it with cool puzzles, but I usually don't get to inherit code from myself.
X = 5 unless invalid_token
Much better than
X = 5 if !invalid_token
Here the humans inability to easily process double negatives, is now an argument for using ‘unless’ in the right circumstances.
I really don’t understand the author’s point about adding extra conditions. They admit that many people will find a single condition with `unless` more readable. They then complain that it becomes unreadable when adding another condition. OK, so swap it out for an `if` at that point. No one is forcing you to keep using `unless` if the requirements change. “You should use a suboptimal solution to cater for unknown fut…
That’s exactly how I use ‘unless’. Simple on condition (no else branch) use cases in one liners, anything more complex, I move to if. Best of both world I’d say!
Earlier quoted context omitted.
It's not pointless, it makes code read better. It's another option to have. It's not meant for every use case. It indicates you don't understand Ruby if you find yourself using an "unless" in a complex boolean operation. It's meant for simple cases like an inline return statement return unless User.exists(id=100)
I'll admit I'm not a Ruby developer, but wow it allows return conditionally inside an expression? What were the language designers thinking?! I can't think of any other language that allows return inside an expression (or break/continue). Let's see: C, C++, C#, Python, Javascript, Object Pascal, Java, Rust; all nope. That is indefensible.
Regardless, all of the languages above except C and maybe Object Pascal can still have control stop in the middle of an expression, since an expression can throw an Exception (indirectly). Returning is not significantly different from that.
Earlier quoted context omitted.
It's not pointless, it makes code read better. It's another option to have. It's not meant for every use case. It indicates you don't understand Ruby if you find yourself using an "unless" in a complex boolean operation. It's meant for simple cases like an inline return statement return unless User.exists(id=100)
I'll admit I'm not a Ruby developer, but wow it allows return conditionally inside an expression? What were the language designers thinking?! I can't think of any other language that allows return inside an expression (or break/continue). Let's see: C, C++, C#, Python, Javascript, Object Pascal, Java, Rust; all nope. That is indefensible.
The visual difference between a ! and an l is not that great, send_email if !user.suspended? or send_email if luser.suspended? The latter could easily be an aggressive dev sending abusive emails to users they dislike enough to call lusers, at first glance at least ...
Sadly `¬` never caught on. But I suppose being visually similar to `-` isn't much better.
I really don’t understand the author’s point about adding extra conditions. They admit that many people will find a single condition with `unless` more readable. They then complain that it becomes unreadable when adding another condition. OK, so swap it out for an `if` at that point. No one is forcing you to keep using `unless` if the requirements change. “You should use a suboptimal solution to cater for unknown fut…
In Common Lisp, there is `unless' and `when' but they don't allow `else' branch. (when CONDITION BODY) (unless CONDITION BODY) The value of the statement is BODY or NIL if it wasn't executed. I can't remember a time when it wasn't clear (though you can always build usage that are unclear).