DEV Community

Cover image for Please don't write confusing conditionals

Please don't write confusing conditionals

Basti Ortiz on July 12, 2023

Have you ever spent more than a few seconds staring at the same line of code? How often did you find conditionals that were tricky to parse? In thi...
Collapse
 
blueberry077 profile image
Marc-Daniel DALEBA

You are right. ヽ(・∀・)ノ
But in general it's better to write this instead:

if (!(!(!(!(!(!(!(!(isAllowed))))))))) {
    doSuccess();
}
Enter fullscreen mode Exit fullscreen mode

( ̄ω ̄)

Collapse
 
somedood profile image
Basti Ortiz

Ah yes... a glorious piece of code right there. 🤣

Collapse
 
dipendracreator profile image
Dipendra Bhardwaj

Ye kya harkat hai

Collapse
 
lionelrowe profile image
lionel-rowe

Affirmative is a good rule of thumb, but I think in some cases, such as HTML's disabled, it makes more sense in the negative, as the usual assumption is that an element is enabled. Which is clearer in intent?

<!-- "negative" naming convention -->
<input name="username">
<input name="password">
<button disabled title="Enter the username and password first!">Submit</button>

<!-- "positive" naming convention -->
<input enabled name="username">
<input enabled name="password">
<button title="Enter the username and password first!">Submit</button>
Enter fullscreen mode Exit fullscreen mode

BTW here's a handy higher-order function when you want to convert a boolean-returning function into its opposite:

function not<T>(fn: (arg: T) => boolean) {
    return (arg: T) => !fn(arg)
}
Enter fullscreen mode Exit fullscreen mode

Usage:

function isOdd(n: bigint) {
    return Boolean(n % 2n)
}

const isEven = not(isOdd)
const nums = [1n, 2n, 3n, 4n]
const odds = nums.filter(isOdd) // [1n, 3n]
const evens = nums.filter(isEven) // [2n, 4n]
Enter fullscreen mode Exit fullscreen mode
Collapse
 
dkechag profile image
Dimitrios Kechagias

Maybe it's time for js to add the "unless" statement that Perl (and Ruby) has? We use a lot of Perl and usually our junior developers come from a javascript background, and the unless statement is one of the things they instantly like.

unless ($isUser && $isGuest) {
    doSomething();
}
Enter fullscreen mode Exit fullscreen mode

Or if you don't need to continue with else statements, you can do the postfix form which developers coming from other languages also seem to quickly find appealing:

doSomething() unless $isUser && $isGuest;
Enter fullscreen mode Exit fullscreen mode

Imagine the above without Perl's $sigils of course, but you can see how it allows an extra level of "positivity".

Collapse
 
somedood profile image
Basti Ortiz

I must admit that I was initially skeptical (to say the least) when I saw the syntax, but that neat one-liner piqued my interest! Personally, that's gonna take some getting-used-to on my end, but I can definitely see why one would "instantly like" such a feature.

Collapse
 
dkechag profile image
Dimitrios Kechagias

And I am with you about early returns. I like to avoid them, except if that will cause a lot of indentation and general ugliness, but I don't think twice about adding them when it comes to this pattern:

return unless $isUser;
Enter fullscreen mode Exit fullscreen mode

Feels natural. I don't use much javascript, but I see how it evolves nicely, so maybe something like that would not be a stretch to see added ;)

Collapse
 
efpage profile image
Eckehard

Some JS programmers make extensive use of the ternary operator istead of conditionals to make their code "more compact". Carefully used, this can lead to readable code:

   // conditionals
   if (fruit === "apple")
       color = "green"
   else
       color = "red"

   // ternary operator
   color = (fruit === "apple") ? green : red
Enter fullscreen mode Exit fullscreen mode

If you misuse the ternray operator as a short form of a conditional, this may make your code virtually unreadable:

something = condition ? nested_condition ? value_if_both_conditions_are_true
    : value_if_nested_condition_is_false : value_if_condition_is_false;
Enter fullscreen mode Exit fullscreen mode

Here is a real life example:

let getPropDescriptor = proto => proto ?
      Obj.getOwnPropertyDescriptor(proto, k) ?? getPropDescriptor(protoOf(proto)) :
      _undefined
Enter fullscreen mode Exit fullscreen mode
Collapse
 
pidgey0403 profile image
Gabrielle Niamat

Totally agree with using the affirmative style for writing conditionals - the logical flow makes much more sense and is very intuitive to follow. Curious to know your thoughts on using the ternary operator in Python or JavaScript?

Collapse
 
somedood profile image
Basti Ortiz

I don't mind them at all as long as they don't go two levels deep and beyond. 😅

Of course, the affirmative style must still follow from that.

name = 'admin' if is_admin else 'user'
Enter fullscreen mode Exit fullscreen mode
const name = isAdmin ? 'admin' : 'user';
Enter fullscreen mode Exit fullscreen mode
Collapse
 
ant_f_dev profile image
Anthony Fung

I think ternary statements are useful for assigning const values where there is some conditional logic to it, like in your example above. I personally find it even easier to read if the two values are put on different lines (but I realise this will be subjective to styling preferences).

const name = isAdmin
  ? 'admin'
  : 'user';
Enter fullscreen mode Exit fullscreen mode

There's only one reason I'll used nested ternaries: when writing variables in a dynamic HTML template and a return value must be computed in a single statement. Of course the workaround there is to compute it above the template where possible and then use it later.

Collapse
 
dyllanjrusher profile image
DyllanUsher

I feel like the example with

Not disallowed throw err
Else success path

Is a common way to structure your code to validate and clean up the success path conditions. Context is important though, I think overall it's more important to discuss the pattern with your team and try to come up with some pattern with justification. Having to negate things is not necessarily a good idea sometimes, but could make sense given the limitations of language, other context around the requirements, or existing patterns in the system.

Collapse
 
zirkelc profile image
Chris Cook

Interesting topic and well explained! 👍🏻

Collapse
 
stalwartcoder profile image
Abhishek Mishra

I like how you making this series 👏
You can also include don't about commit message as well in this series :)

Collapse
 
somedood profile image
Basti Ortiz

Thanks! I will certainly put this in my to-do list. 🙇‍♂️

Collapse
 
catsarebetter profile image
Hide Shidara

It's wild how many of these bad conditionals are in production code at top tier startups

Collapse
 
tracygjg profile image
Tracy Gilmore

Readers of this article might be interested in my post on De Morgan's Law.
dev.to/tracygjg/de-morgans-law-a-l...

Collapse
 
mylazuardy profile image
Ardy Lazuardy

agree! but it takes a lot of time and requires coding experience. happened to me :sad