Open khanhicetea opened 1 month ago
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.
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
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 {
...
}
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