You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Complex conditional expressions can make the code difficult to read because they interrupt the "flow" of the main program.
If one instead extracts them to a boolean function/variable, the new conditional expression much more readable and, as a side effect, the new function/variable introduces a reusable abstraction in the codebase.
Example
Actual
if (looks_like_a_duck(x) &&
swims_like_a_duck(x) &&
quacks_like_a_duck(x)) {
...
}
Note that this is the simplest cases, but one can imagine that the expression depend on different objects, and so the boolean function can be multi-parameter (e.g. is_duck(x, y, z)).
Configurable
As for what constitutes a complex conditional expression can be configurable. The default will be 2L. That is, any expression with more than two operands will set off this linter. But users can set this to a higher or a lower value (e.g. if someone prefers to always use a boolean function in a conditional expression to improve readability).
The text was updated successfully, but these errors were encountered:
Counter-argument to factoring out a method: It moves the behavior somewhere else, so if you want to understand the code, you need to read in two locations and remember the definition.
Counter-argument to factoring out a method: It moves the behavior somewhere else, so if you want to understand the code, you need to read in two locations and remember the definition.
But won't this criticism apply in general to any refactoring where part of the code is moved to a new routine/method/function? In other words, this counter-argument speaks against the whole idea of modularizing the codebase using smaller, reusable functions with expressive names.
Preamble
Complex conditional expressions can make the code difficult to read because they interrupt the "flow" of the main program.
If one instead extracts them to a boolean function/variable, the new conditional expression much more readable and, as a side effect, the new function/variable introduces a reusable abstraction in the codebase.
Example
Actual
Suggested-1: boolean function
Suggested-1: boolean variable
Note that this is the simplest cases, but one can imagine that the expression depend on different objects, and so the boolean function can be multi-parameter (e.g.
is_duck(x, y, z)
).Configurable
As for what constitutes a complex conditional expression can be configurable. The default will be 2L. That is, any expression with more than two operands will set off this linter. But users can set this to a higher or a lower value (e.g. if someone prefers to always use a boolean function in a conditional expression to improve readability).
The text was updated successfully, but these errors were encountered: