6 ms·

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

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 future requirements” is a terrible argument.

tebbers 4y ago
Exactly my first thought too.
roboben 4y ago
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!
- aqme28 4y ago
  That’s the generally recommended style! I hate this post. It’s arguing against something that is well known to be a bad practice (that’s fine), but it seems to put the fault for this on Ruby itself.
- JeremyNT 4y ago
  Yes! And rubocop can encourage the use of 'unless' in only these simple situations where it does enhance legibility. https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/UnlessElse https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/Unle... https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/UnlessLogicalOperators https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/Unle...
thedanbob 4y ago
To be fair, he makes the point that > there’s this bizarre quirk of human psychology where developers retain the unless against all odds I have refactored a number of unwieldy `unless` statements written by colleagues so maybe there’s something to that.
Draiken 4y ago
I believe this is somewhat prevalent in the Ruby community as of late where people try as hard as possible to "lock down" the language and limit the ways you can get to a solution in the name of the proverbial "ease of understanding". I wholeheartedly disagree and believe we should instead grow the developers to understand these different approaches as opposed to labeling half of the language "bad practice". As I said in another comment. Ruby was built to have multiple ways of doing the same tasks and criticizing it for this is... pointless. Yes people can create monstrosities with all of these variations, but that's true with any powerful tool. If you dislike Ruby for being Ruby, pick another language.
- techdragon 4y ago
  I love an expressive programming language, it’s why Go makes me feel like I’m brushing my teeth with sandpaper… But there’s such a thing as too much flexibility, expressiveness and flexibility often go hand in hand as flexible language lets you make things as expressive as you want… but things can be expressive without the same level of flexibility if they are well designed. I find Rust strikes a good balance for low level language work, it feels more expressive than C because of higher level language features but it’s not necessarily as flexible as C with things like the borrow checker nagging you to be safe unless you turn it off. Lisp… too flexible, too expressive. Lisp code reminds me of the phrase “that depends on what the definition of is, is”. Scheme and scheme likes including weird step cousins like JavaScript share the unfortunate result of this and your drowning in custom DSLs and no one quite codes the same way unless you have rigorous tooling to enforce a team style. Ruby falls foul of this for me too. It’s too flexible, it’s very expressive and I enjoyed reading the tutorials and learning the basics. But the moment I discovered real code I was immediately recoiling in horror …. It was a disaster… a spaghetti mess of overrides redefining and meta-programming in general. It made it impossible for me to ever trust the environment I coded it since I had to constantly inspect everything to make sure someone hadn’t done something crazy like enhanced the “+” sign to transform numbers to strings for avoiding something like a sql injection risk in a specific context and whoopsie, leaked the behaviour globally so now any time you added integers you got concatenated strings… but only after the library was dynamically loaded on first query … maddening stuff… Stuff like this is why ruby is too flexible.
doodpants 4y ago
Indeed. I personally never fail to avoid not using "unless", unless there isn't a lack of extra conditions such that not refraining from instead using "if" wouldn't avoid not being less clear.
- scambier 4y ago
  I'm not sure that making this sentence as obtuse as possible is a great idea to convey your point.
  - lsaferite 4y ago
    Making it as obtuse as possible was very likely the point.
- airstrike 4y ago
  SURGEON GENERAL'S WARNING: reading this sentence before consuming caffeine may cause significant brain damage
asdajksah2123 4y ago
The author's point is that conditions in code tend to add up. What may start as a simple single condition, may not remain that way a year later. Since there's always the possibility of a certain conditional becoming more complicated, it makes sense to opt for the equivalent solution that makes adding those additional conditions easier. The alternative is to change the keyword when you add those additional conditions, but in most workplaces it's very possible that someone with less rigor than you might come in and add those new conditions and not make the change. And then if you want to add a new condition you need to parse and understand the more complicated new conditional first, before you can change it. This adds a lot of maintainability risk for what appears to be, in the best case, a very minor benefit.
- WillPostForFood 4y ago
  That strikes me as a premature optimization. If you have a single condition, and unless makes it more readable, use unless. If the conditions do pile up in the future, change it to an if.
  - quest88 4y ago
    Great, now you've got this weird logic on your style guide that your code reviewers will have to point to, and hopefully the new engineers on your team will remember. But maybe they're in a hurry and will quickly add another expression just this one time, multiplied by many engineers. It's far simpler to ban use of unless.
    - WillPostForFood 4y ago
      It is neither weird, nor complex. Use unless in cases where the if has a single, negative condition.
- draw_down 4y ago
- shortcake27 4y ago
saghm 4y ago
> “You should use a suboptimal solution to cater for unknown future requirements” is a terrible argument Not exactly the same, but over the years I've heard people argue against having super customized shell configurations (e.g. completions, prompts, highlighting) because they won't be available if you have to use a different environment (e.g. sshing into a temporary cloud server to debug something failing in CI). I don't pretend that other people will value tradeoffs the same as me, but it's a mindset I can't really imagine ever having. I'd rather be happy most of the time even if I know I'm going to be unhappy for short periods occasionally in the future, and I don't really think the slight efficiency gain in the uncommon case due to being used to not having nice features is going to outweigh the larger efficiency gain for the much more common case. At the risk of straying entirely off-topic, I've seen this in non-professional contexts at times as well; I recently had a friend in an online game mention that he doesn't like to utilize a convenience feature that happens for a couple weeks each year as part of a special even because he would miss it too much the rest of the time. While I don't think the tradeoff is quite as obvious to me for this sort of thing, I feel like occasionally having a fun temporary addition is worth it just for the change of pace, and I'm generally able to adapt to the loss of a minor convenience relatively quickly after losing it. It seems sort of like a question of "maximizing peak happiness" versus "minimizing peak unhappiness" or even "maximizing average happiness"; I like having something to get excited about every now and then even if it leads to feeling blase about things for a bit later because I get bored if things stay the same for too long.
- meatmanek 4y ago
  As an analogy to your shell customization thing: I switched from QWERTY to Dvorak a long time ago, a few years after learning to touch type. Does it make me more efficient on my own computer? Probably slightly -- Dvorak really is a well-designed keyboard layout, but it's impossible to know whether my WPM is any higher than it would've been on QWERTY. However, I make way more mistakes and type way more slowly whenever I sit down at a QWERTY keyboard. I had to re-learn how to touchtype QWERTY after switching to Dvorak, and my skill never got back to the same level. It also leads to extra inconvenience every time I lend my computer to someone else, install a new OS, etc. I think this means my average typing speed (weighted average of the time spent at Dvorak keyboards + QWERTY keyboards) is probably flat or possibly lower than if I had just stuck with QWERTY. When combined with all the effort I spent learning Dvorak, re-learning QWERTY, and making many mistakes in the early years, I think my lifetime productivity is probably even lower. I don't recommend that people switch, even if I think Dvorak really is a better layout.

tebbers 4y ago

Exactly my first thought too.

roboben 4y ago

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!

aqme28 4y ago
That’s the generally recommended style! I hate this post. It’s arguing against something that is well known to be a bad practice (that’s fine), but it seems to put the fault for this on Ruby itself.
JeremyNT 4y ago
Yes! And rubocop can encourage the use of 'unless' in only these simple situations where it does enhance legibility. https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/UnlessElse https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/Unle... https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/UnlessLogicalOperators https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/Unle...

thedanbob 4y ago

To be fair, he makes the point that > there’s this bizarre quirk of human psychology where developers retain the unless against all odds I have refactored a number of unwieldy `unless` statements written by colleagues so maybe there’s something to that.

Draiken 4y ago

I believe this is somewhat prevalent in the Ruby community as of late where people try as hard as possible to "lock down" the language and limit the ways you can get to a solution in the name of the proverbial "ease of understanding". I wholeheartedly disagree and believe we should instead grow the developers to understand these different approaches as opposed to labeling half of the language "bad practice". As I said in another comment. Ruby was built to have multiple ways of doing the same tasks and criticizing it for this is... pointless. Yes people can create monstrosities with all of these variations, but that's true with any powerful tool. If you dislike Ruby for being Ruby, pick another language.

techdragon 4y ago
I love an expressive programming language, it’s why Go makes me feel like I’m brushing my teeth with sandpaper… But there’s such a thing as too much flexibility, expressiveness and flexibility often go hand in hand as flexible language lets you make things as expressive as you want… but things can be expressive without the same level of flexibility if they are well designed. I find Rust strikes a good balance for low level language work, it feels more expressive than C because of higher level language features but it’s not necessarily as flexible as C with things like the borrow checker nagging you to be safe unless you turn it off. Lisp… too flexible, too expressive. Lisp code reminds me of the phrase “that depends on what the definition of is, is”. Scheme and scheme likes including weird step cousins like JavaScript share the unfortunate result of this and your drowning in custom DSLs and no one quite codes the same way unless you have rigorous tooling to enforce a team style. Ruby falls foul of this for me too. It’s too flexible, it’s very expressive and I enjoyed reading the tutorials and learning the basics. But the moment I discovered real code I was immediately recoiling in horror …. It was a disaster… a spaghetti mess of overrides redefining and meta-programming in general. It made it impossible for me to ever trust the environment I coded it since I had to constantly inspect everything to make sure someone hadn’t done something crazy like enhanced the “+” sign to transform numbers to strings for avoiding something like a sql injection risk in a specific context and whoopsie, leaked the behaviour globally so now any time you added integers you got concatenated strings… but only after the library was dynamically loaded on first query … maddening stuff… Stuff like this is why ruby is too flexible.

doodpants 4y ago

Indeed. I personally never fail to avoid not using "unless", unless there isn't a lack of extra conditions such that not refraining from instead using "if" wouldn't avoid not being less clear.

scambier 4y ago
I'm not sure that making this sentence as obtuse as possible is a great idea to convey your point.
- lsaferite 4y ago
  Making it as obtuse as possible was very likely the point.
airstrike 4y ago
SURGEON GENERAL'S WARNING: reading this sentence before consuming caffeine may cause significant brain damage

asdajksah2123 4y ago

The author's point is that conditions in code tend to add up. What may start as a simple single condition, may not remain that way a year later. Since there's always the possibility of a certain conditional becoming more complicated, it makes sense to opt for the equivalent solution that makes adding those additional conditions easier. The alternative is to change the keyword when you add those additional conditions, but in most workplaces it's very possible that someone with less rigor than you might come in and add those new conditions and not make the change. And then if you want to add a new condition you need to parse and understand the more complicated new conditional first, before you can change it. This adds a lot of maintainability risk for what appears to be, in the best case, a very minor benefit.

WillPostForFood 4y ago
That strikes me as a premature optimization. If you have a single condition, and unless makes it more readable, use unless. If the conditions do pile up in the future, change it to an if.
- quest88 4y ago
  Great, now you've got this weird logic on your style guide that your code reviewers will have to point to, and hopefully the new engineers on your team will remember. But maybe they're in a hurry and will quickly add another expression just this one time, multiplied by many engineers. It's far simpler to ban use of unless.
  - WillPostForFood 4y ago
    It is neither weird, nor complex. Use unless in cases where the if has a single, negative condition.
draw_down 4y ago
shortcake27 4y ago

saghm 4y ago

> “You should use a suboptimal solution to cater for unknown future requirements” is a terrible argument Not exactly the same, but over the years I've heard people argue against having super customized shell configurations (e.g. completions, prompts, highlighting) because they won't be available if you have to use a different environment (e.g. sshing into a temporary cloud server to debug something failing in CI). I don't pretend that other people will value tradeoffs the same as me, but it's a mindset I can't really imagine ever having. I'd rather be happy most of the time even if I know I'm going to be unhappy for short periods occasionally in the future, and I don't really think the slight efficiency gain in the uncommon case due to being used to not having nice features is going to outweigh the larger efficiency gain for the much more common case. At the risk of straying entirely off-topic, I've seen this in non-professional contexts at times as well; I recently had a friend in an online game mention that he doesn't like to utilize a convenience feature that happens for a couple weeks each year as part of a special even because he would miss it too much the rest of the time. While I don't think the tradeoff is quite as obvious to me for this sort of thing, I feel like occasionally having a fun temporary addition is worth it just for the change of pace, and I'm generally able to adapt to the loss of a minor convenience relatively quickly after losing it. It seems sort of like a question of "maximizing peak happiness" versus "minimizing peak unhappiness" or even "maximizing average happiness"; I like having something to get excited about every now and then even if it leads to feeling blase about things for a bit later because I get bored if things stay the same for too long.

meatmanek 4y ago
As an analogy to your shell customization thing: I switched from QWERTY to Dvorak a long time ago, a few years after learning to touch type. Does it make me more efficient on my own computer? Probably slightly -- Dvorak really is a well-designed keyboard layout, but it's impossible to know whether my WPM is any higher than it would've been on QWERTY. However, I make way more mistakes and type way more slowly whenever I sit down at a QWERTY keyboard. I had to re-learn how to touchtype QWERTY after switching to Dvorak, and my skill never got back to the same level. It also leads to extra inconvenience every time I lend my computer to someone else, install a new OS, etc. I think this means my average typing speed (weighted average of the time spent at Dvorak keyboards + QWERTY keyboards) is probably flat or possibly lower than if I had just stuck with QWERTY. When combined with all the effort I spent learning Dvorak, re-learning QWERTY, and making many mistakes in the early years, I think my lifetime productivity is probably even lower. I don't recommend that people switch, even if I think Dvorak really is a better layout.