Wrong example in [Complex conditionals]

[khanhicetea]

Hi @zakirullin , your article is good :)

Btw, this example is some kind wrong as code (though it looks the same in domain-space)

The above code acts like a logic gate of 3 ANDs of 3 expressions (mean it can include function calls)
The below (solution) acts like a logic gate of 3 ANDS of 3 variables store of excecuted expression results

[zakirullin]

Hi @khanhicetea, thanks for the feedback!

This is both an artificial language and an artificial example. Also, I didn't provide EBNF for the language, maybe its grammar doesn't have function calls in condition :) But you're right, in the second case all function calls (if there are any) would be executed regardless of previous conditions, which in some cases may cause issues.

I am not sure if we should overload the reader with all sorts details or tricky edge-cases while conveying this general idea.

[seanblonien]

Yea I think the purpose of the example with intermediate values is still conveyed succinctly, and I don't think many people would be confused by that edge case, so I think it makes sense as is

For that given edge case, I think early-return/guard-clauses would be the best, least cognitive load alternative to allow for short-circuiting conditions. But I think showing that in the example just to support that edge case would do more harm than good when it comes to understanding the general idea. I could see adding a small "note" or something similar noting that edge case, but the original examples seems good as it is now

[khanhicetea]

How about this, right in logic code flows and in business domain ( It's emphasize the business dependencies , easy to read, easy to understand )

The request is allowed if only it's valid
The request is secured if only its' allowed
I think most of the time I use 3 AND logic gates (80% I care about the last one) 😃

isValid = val > someConstant
isAllowed = isValid && (condition2 || condition3)
isSecure = isAllowed && (condition4 && !condition5)
// 🧠, we don't need to remember the conditions, there are descriptive variables
if isSecure {
    ...
}

[pegas123]

I aso have an issue with the example of Complex Conditionals.

The cognitive load on complex conditionals can be decreased by

1. expressive naming of variables,
2. consistency in expressions.

You introduced local variables to use the #1. You also got rid (partially) of unneeded parenthesis (#2.) without talking about it.

if condition1 // is it valid?
&& (condition2 || condition3) // is it allowed?
&& condition4 // and is it secured too?
&& !condition5 // --//--
{
...
}
is already much better readable and understandable. I would recommend to use a local variable instead of a comment only in a case when the expression if too complicated to place a comment behind it (is there an option to describe conditions 4 and 5 individually?). Local variables, even when well named, have some cognitive load on their own, because if is not obvious whether the variable is used somewhere else.