DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Discussion on: You don't need "if"

Collapse
ogranada profile image
Andres Granada

Interesting article, definitely it shows a different way to think, but, I think we need to have in mind that readability is not about how long is the code or how many sentences we have in a file, is about structure and experience. As an example, if you’re working with a junior dev maybe a ternary operator is not the best option to make the code readable for him, and in many cases the compiler/transpiler/interpreter transform the if and the ternary operator in an if.

Collapse
lukeshiru profile image
Luke Shiru Author • Edited on

A few things:

  1. About the readability, you're right! I completely forgot to show how it looks like when you move stuff to functions with clear names, so you go from array.map(/* a bunch of code here inline */) to something like array.map(double) which is way more readable. I update the article with a new section that I forgot from my notes here (new section "Edit: Improving readability").
  2. You can teach a junior to read a ternary in 5 minutes, is far from being a hard concept.
  3. Minifiers might turn ifs into ternaries or shortcircuits, but the idea here is to show the power it has to use them oneself. If you don't write the else for an if, the minifier might turn it into condition?value:undefined, which isn't ideal. Ideally you should change that undefined, unless you intentionally wanted to return a "nullish" value.

Thanks for reading!

Edit: Just to add to this, the post wasn't even pointed at juniors, it's set to 7 which is "almost expert", so yeah, this is more of a post for folks that are "stuck in their ways".

Screenshot showing the level of this post set to 7

Collapse
andreidascalu profile image
Andrei Dascalu

Just a note: readability isn’t about understanding the concept or not. If a dev doesn’t know how to read a ternary at all, that’s a blocker. Readability is about how fast you understand the code by glancing at it. If a dev needs to pause to decipher a ternary ( maybe a multi level one), that’s a readability issue.
Code doesn’t need to be clever, it needs to be maintainable.

lukeshiru profile image
Luke Shiru Author

That's a pretty common complaint about ternaries, but I'll argue that this:

condition ? "true value" : "false value";
Enter fullscreen mode Exit fullscreen mode

Is a readable (or maybe even more) than this:

if (condition) {
    return "true value";
} else {
    return "false value";
}
Enter fullscreen mode Exit fullscreen mode

I learnt ternaries when I was learning programming, and it was a pretty easy concept to grasp (for me and my classmates as well). Usually I see this "ternaries are hard to read for juniors", but the thing is that if becomes hard to read, that's a sign that you need to move some functionality away to its own function or reconsider part of your logic (as I mentioned in the article, I see that as a pro). If you find that you can't think conditions without thinking in the if keyword, that might be a problem. The idea is that you should be able to think logic branches as actual branches and not as "if/else" blocks. Don't get me wrong, I don't support stuff like nesting ternaries inside ternaries or anything like that that will become quite cryptic in no time, but as I mentioned in the article, ternaries have some advantages over ifs that from my point of view are pretty valuable.

As you said, devs shouldn’t need to pause to decipher code in general, my point is that when using ternaries, if you need to stop to decipher, that only means that you need to move that code to a function with a clear name so we can abstract that "blockage" away.

Thanks for reading and commenting!

andreidascalu profile image
Andrei Dascalu

well, for a large part readability is in the eye of the beholder and such decisions should be taken based on team discussions and clear metrics.

But, three small details, just for the sake of the discussion:

if (condition) {
    return "true value";
} else {
    return "false value";
}
Enter fullscreen mode Exit fullscreen mode

-> as a nitpick, you don't need an else at all. You have return statements.

  1. if 's can also be taken in separate functions to the same effect with the added bonus that you'd never need to use else in that situation, you'd just return.

  2. The top advantage of if is that in most languages you don't re-introduce other symbols and/or change their meaning. if (condition) { is a pretty clear statement using the same block separators. That block may have as many or as few lines as needed, which isn't the case of a ternary that's meant to be used only in the simplest of cases. So then why have a double standard at all? if statements are also portable between languages, while ternaries can be different (if they exist at all). Just look at PHP and how many different versions of ternaries it has. Fewer lines of code doesn't always mean more readable. Depending on context it can have the opposite effect.

Granted, I'd use a ternary in one case (and one alone), to replace

if (condition) {
   myVar = "xxxx";
} else {
   myVar = "yyyy";
}
Enter fullscreen mode Exit fullscreen mode

to

myVar = (condition) ? "xxxx" : "yyyy";
Enter fullscreen mode Exit fullscreen mode

though I'd still ask myself if it's worth creating a double standard and slightly increase cognitive load since I can also improve my code with

myVar = "yyyy";

if (condition) {
  myVar = "xxxx";
}
Enter fullscreen mode Exit fullscreen mode
vforteli profile image
Verner Fortelius • Edited on

I would agree about the readability, but I think the biggest benefit of a ternary in cases like these is being able to use const directly

lukeshiru profile image
Luke Shiru Author

readability is in the eye of the beholder

100% agree. For me, for example, the early return approach is less readable, I always try to keep my functions with a single point of output. When I see a block like:

if (condition) return "true value";
return "false value";
Enter fullscreen mode Exit fullscreen mode

I read "If condition then return "true value", return "false value"" ... I know that the early return will break the function so the "false value" woundl't run, but is just less readable from my point of view than just doing:

condition ? "true value" : "false value"
Enter fullscreen mode Exit fullscreen mode

Which I read as "condition? Then "true value". Else "false value"". I actually would prefer an if/else over an early return.

The top advantage of if is that in most languages you don't re-introduce other symbols and/or change their meaning.

I mean, ternaries are pretty much everywhere, but even if you come from a language that doesn't have them, is a pretty easy concept to understand.

That block may have as many or as few lines as needed, which isn't the case of a ternary that's meant to be used only in the simplest of cases.

I mentioned this on the article, but I see that as yet another advantage of ternaries, mainly because if you need more logic in that condition, then you need to move that logic away to its own function. You can do this with ifs as well, but is not "enforced" by the language, you just have to agree with your whole team to try to keep conditions simple and move complex branches to their own functions.

Fewer lines of code doesn't always mean more readable. Depending on context it can have the opposite effect.

I agree, that's why in the past I wrote an article talking about the importance of naming. I love functional programming, but for example hate how Haskell uses single letters for everything, making it short but extremely and unnecessarily hard to read. My idea is that if you move logic away to keep your ternaries short, those functions need to have significant names that make the content of that logic branch obvious without having to go into the function to see what it does.

Thanks for adding comments like this one! Actually showing more examples makes it way more useful for everyone!

Some comments have been hidden by the post's author - find out more