26 ms·

As the article starts to explore, it's more useful in the context of a single line conditional with a single boolean to evaluate, or what I sometimes call a "da

As the article starts to explore, it's more useful in the context of a single line conditional with a single boolean to evaluate, or what I sometimes call a "dangling conditional". This is valid ruby: do_something if boolean_expression All unless does is allow you to negate it using an expression that's more natural to most people do_something unless boolean_expression To me the negation of an if with ! is less clear in this context. For example: puts "That's a prime" if is_prime?(variable) makes sense. So does: puts "That's not a prime!" unless is_prime?(variable) Far more so than: puts "That's not a prime!" if !is_prime?(variable) The author decides however to add more conditionals. Fine, don't do that. Or that it's unreadable in some contexts. Fine, don't do that either. The whole point of Ruby - the only reason it really exists - is that it should be fun and easy and not require you to spend too much time stressing over rules. If you read a piece of Ruby and don't like it, change it. It's not Python - there is more than one way. Use the way that makes sense in the context you're using it. If you can't trust yourself or your team to do that wisely in a project, consider changing languages, because guess what? The language isn't going to change because you don't like that thing.

torton 4y ago
The impetus to write the article seems to be Rubocop, whose rules are suggesting a specific way of doing things. But specific instances of a specific rule can be overridden, and if a rule proves itself to be more trouble than it's worth it can be disabled entirely. I would go so far as to suggest jumping into Rubocop "cold turkey", meaning all rules on, is not very helpful on an existing codebase. The way my team approached Rubocop on a particular large legacy codebase was to start with a few hand picked rules that were non-controversially good, and discuss new rules one at a time as we gradually fixed the existing issues.
neilv 4y ago
Maybe these dangling conditionals are easier for you to read, but not for me. Were I reading through real-world code that did things like that: "OK, then we do this, and then we do that, and then-- Oh wait! Backtrack! We didn't do that thing at all! ... Now where were we, on our actual bug, before some very special person's syntactic speed bumps?"
- Draiken 4y ago
  But these are not absolutes. You can learn to use and read `unless` just as effortlessly as you did with `if`. I didn't learn to use/read `unless` on college. But I did focus on trying to learn these things and today I have another tool in my belt. It's an opportunity to get better at something versus banning it from usage because we aren't used to it. Growing is, for me, almost always the right choice.
  - neilv 4y ago
    Dangling conditionals the parent was talking about. Where the conditional comes after the thing you told it to do. Computationally, that's increased backtrack/lookahead for no good reason. Regarding `unless`, that's a different matter. I was actually the person who proposed adding an `unless` syntax to Racket, and later regretted it. I was bikeshedding, before I knew something more useful to do. This isn't about learning new things to add to our mental toolbox. This is about our difficulty to introspect on our own thought processes and effectiveness, and about bikeshedding. Software engineering competence is hard, or we wouldn't have all the huge expenditures, slipped project schedules, and rampant security vulnerabilities. Redundant syntax forms that objectively makes it harder to read (see the lookahead and parser theory), solely because someone imagined it was sometimes easier to read this way (see dying languages Perl and Ruby) is just wasting our time, when we could be tackling the real problems. (Though us pulling theories about programming and process out of our posteriors, to defend to the death, is arguably half our problem in industry right now.)
ufmace 4y ago
I agree with this - I always found the single ! in conditionals to be too easy for your eyes to slide past and miss. Using `unless` makes it jump out harder that you're only doing the thing if the condition is `false`.

torton 4y ago

The impetus to write the article seems to be Rubocop, whose rules are suggesting a specific way of doing things. But specific instances of a specific rule can be overridden, and if a rule proves itself to be more trouble than it's worth it can be disabled entirely. I would go so far as to suggest jumping into Rubocop "cold turkey", meaning all rules on, is not very helpful on an existing codebase. The way my team approached Rubocop on a particular large legacy codebase was to start with a few hand picked rules that were non-controversially good, and discuss new rules one at a time as we gradually fixed the existing issues.

neilv 4y ago

Maybe these dangling conditionals are easier for you to read, but not for me. Were I reading through real-world code that did things like that: "OK, then we do this, and then we do that, and then-- Oh wait! Backtrack! We didn't do that thing at all! ... Now where were we, on our actual bug, before some very special person's syntactic speed bumps?"

Draiken 4y ago
But these are not absolutes. You can learn to use and read `unless` just as effortlessly as you did with `if`. I didn't learn to use/read `unless` on college. But I did focus on trying to learn these things and today I have another tool in my belt. It's an opportunity to get better at something versus banning it from usage because we aren't used to it. Growing is, for me, almost always the right choice.
- neilv 4y ago
  Dangling conditionals the parent was talking about. Where the conditional comes after the thing you told it to do. Computationally, that's increased backtrack/lookahead for no good reason. Regarding `unless`, that's a different matter. I was actually the person who proposed adding an `unless` syntax to Racket, and later regretted it. I was bikeshedding, before I knew something more useful to do. This isn't about learning new things to add to our mental toolbox. This is about our difficulty to introspect on our own thought processes and effectiveness, and about bikeshedding. Software engineering competence is hard, or we wouldn't have all the huge expenditures, slipped project schedules, and rampant security vulnerabilities. Redundant syntax forms that objectively makes it harder to read (see the lookahead and parser theory), solely because someone imagined it was sometimes easier to read this way (see dying languages Perl and Ruby) is just wasting our time, when we could be tackling the real problems. (Though us pulling theories about programming and process out of our posteriors, to defend to the death, is arguably half our problem in industry right now.)

ufmace 4y ago

I agree with this - I always found the single ! in conditionals to be too easy for your eyes to slide past and miss. Using `unless` makes it jump out harder that you're only doing the thing if the condition is `false`.