10
I was reading a little bit of Clean Code. The book talks about "good programming practices", and on the Internet, in one of the slides it is said that:
Boolean arguments, in general, are not good.
I didn’t understand the reason for this phrase. Although I’m not talking about a specific language, I wanted to understand the reason better.
9
Boolean arguments, in general, are not good. This phrase is correct?
In general are not good.
If yes, what is the problem with booleans? Because booleans are not good arguments?
It gives little meaning, makes the code less readable. So it causes no technical problem, it’s just a matter of style.
I don’t remember whether the book explains it or not. I know this book doesn’t explain much. What is not explained can’t be taken much into account.
It can cause some difficulty along with other mechanisms. Imagine that the parameter has a default value false and you forget that, you can take a value that was not what you wanted, but the problem there is not the boolean itself, could occur the same with other types.
There is the myth that using this function has more than one responsibility. This is nonsense because we do not know beforehand whether it has or not. Knowing this does not guarantee anything. Some cases where boolean is used may occur this.
This is one of those wrong arguments that happens to be disseminated because people do not understand what is happening, only repeat what they read.
Of course you have cases like this. In general it is even better to do so when the algorithm needs to vary according to an information that is only a detail of the algorithm.
If you create two methods to avoid the boolean argument the maintenance gets worse and hurts the principle that a change should be made in only one place since it passes always require change in two methods and you can forget to do in the other. It is harder to forget to do in the same algorithm and probably the test will catch the problem if it is in the same.
What may occur in certain cases is that it diminishes the cohesion, But it depends, so I don’t like cake recipes, good practice. If the cohesion is affected, if the function actually does more than one thing, the problem is not the argument being boolean, the problem even occurs without using a boolean. So looking at the boolean is looking at the wrong problem.
Some say this exposes a detail of implementation. It may occur in some case, but not at all, and the solution other than that, no matter which, will probably have the same problem. Martin Fowler has a solution.
Imagine a:
Compare(true);
What this argument means?
What kinds of arguments would be good?
In general we prefer an enumeration with two states that indicate the same thing as the true and the false, but now with specific names that say something. So now imagine:
Compare(Case.Sensitive);
Now you know what the argument is? It gives a lot more context, right?
It’s even easier to give a find in the code, right? There is something to look for. Search for a true you won’t find what you want.
There is another advantage to an emergency case. Of course, such a solution should not be necessary, but we are not always in ideal conditions. Think that at some point you pass having a third state for this algorithm, what to do if you used a boolean? There is not much solution but to create another argument, if you get lucky in a language that has optional arguments. It’s pretty ugly. If you use an enumeration just add a new member to it, although in general is not the most recommended, is not so critical.
Another solution is to create separate functions for the two tasks and there in her name will have a context of what she is doing. It can be a solution in certain situations. So:
CompareCaseSensitive();
If the language allows the named argument, the boolean may not be so bad as long as the consumer of the function names the argument always and it is guaranteed that a boolean will always be suitable, something like that:
Compare(CaseSensitive : true);
I put in the Github for future reference.
It has enough language to force the argument to be named in certain cases (Swift).
0
I found this article quite interesting that can resolve your doubt. Here is an excerpt from the article.
"This is one of the worst practices. Booleans mean that their function will be playing a totally different role depending on the state of only one variable. This will make our role have more than one responsibility, which means that any change in the function code we will have to take into account the other roles that the function is playing."
Source: http://blog.triadworks.com.br/clean-code-boas-praticas-para-argumentos-de-funcao
Browser other questions tagged encoding-style language-independent boolean argument
You are not signed in. Login or sign up in order to post.
Why not use a boolean parameter?
– rray
I think it’s dup. right? And soon mine, I didn’t even remember her. I think I’ll use Renan’s answer and maybe others to improve mine here.
– Maniero