71–80 of 326 posts
I take issue with the word unless. "Un" means opposite and "Less" means, well less, so unless means more. So `unless` should just be a straight alias for `if`.
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.
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.
Er, what?
You understand almost everything in Rust is an expression right?
let x = if yeah_nah() { return 5; } else { "X" };
Rust's type inference engine is fine with this because under type arithmetic all the values fit in a single type, the type of "X" - &'static str - there are no values on the left to disrupt that.
I've been writing Ruby for 20+ years and "unless" (the whole language, actually) immediately clicked for me when I first learned it. That said, I only use it in 2 cases: * as a trailing condition (do_something unless this), mainly for early returns * as the only arm of a multi-line block (unless this ... end, no "else" blocks - Rubocop would yell at me anyway) And then only if the condition is either a simple value,…
Of course one can avoid it at all but of course one cannot avoid to spend time on it when reading somebody's else code.
I've been writing Ruby for 20+ years and "unless" (the whole language, actually) immediately clicked for me when I first learned it. That said, I only use it in 2 cases: * as a trailing condition (do_something unless this), mainly for early returns * as the only arm of a multi-line block (unless this ... end, no "else" blocks - Rubocop would yell at me anyway) And then only if the condition is either a simple value,…
do not do unless not
of some fun programming language whose name I forgot.
A long time ago, a friend code reviewed and asked me to change to the most common condition first, as advocated in the Code Complete book (which I hadn't read at the time).
I still think it reads better if/else as true/false, but I am also big on having standards and a coding style, even if I disagree with them.
I mean, unless there's a lack of coding standard I will follow it.
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)
God that's such a landmine when reading code. Seeing a return without an explicit change of scope... Why ? To save one line ? Yep that's why I hate ruby - worked on one mature codebase for a year and after seeing various such gems used across the project - from >10 devs - I'm confident I will never touch the language again.
Earlier quoted context omitted.
Ruby has "not", but the precedence rules between "not" and "!" differ
Well I really showed myself up as commenting on a topic that I know nothing about! :-) But that's actually ideal in this context, a really low precedence operator is exactly what you want because you can swap `unless` for `if not` without worring about extra parentheses: send_email if not user_suspended? || user_opt_out?
I generally avoid `not`, `and`, `or` keywords.