Boolean arguments, in general, are not good?

  

Boolean arguments, in general, are not good. Is this sentence correct?

In general they are not good.

  

If yes, what is the problem with booleans? Why booleans are not good arguments?

It gives little meaning, makes the code less readable. So it does not cause technical issues, it's just a matter of style.

I do not remember if the book explains this or not. I know this book does not explain much. What is not explained can not be taken into account.

It can cause some difficulty along with other mechanisms. Imagine that the parameter has a default value false and you forget it, you can get a value that was not what you wanted, but the problem is not the boolean itself, it could be the same with other types.

There is the myth that using this function has more than one responsibility. This is bullshit because we do not know in advance if it has or not. That does not guarantee anything. Some cases where boolean is used may occur. This is one of those misguided arguments that happen to be disseminated because people do not understand what is happening, they just repeat what they read. Of course there are cases like this. In general it is even better to do so when the algorithm needs to vary according to information that is just a detail of the algorithm. If you create two methods to avoid the Boolean argument the maintenance gets worse and it hurts the principle that a change should be made in one place since pass requires always change in two methods and you can forget to do in the other. It is harder to forget to do the same algorithm and the test will probably catch the problem if it is the same.

What may happen in certain cases is that this decreases cohesion , but it depends on the case, so I do not like cake recipes, good practices. If cohesion is affected, if the function actually does more than one thing, the problem is not the argument being boolean, the problem occurs even without using a boolean. So looking at the boolean is looking at the wrong problem.

Some people say that this exposes an implementation detail. It may occur in some case but not at all and the different solution of this, no matter which one, will probably have the same problem. Martin Fowler has a solution for this .

Imagine one:

Compare(true);

What does this argument mean?

  

What kind 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 even makes it easier to give find in the code, right? You have what to look for. Searching for a true will not find what you want.

There is another advantage to an emergency case. Of course this type of solution should not be necessary, but we are not always in ideal conditions. Think that at some point you happen to have a third state for this algorithm, what do you do if you used a Boolean? There's not much else to come up with unless you make another argument if you're 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 this is usually not the most recommendable , not is so critical.

Another solution is to create separate functions for the two tasks and there in the name of it will have a context of what you are doing. It can be a solution in certain situations. So:

CompareCaseSensitive();

If the language allows the named argument, the boolean may not be that bad, as long as the function consumer names the argument always and is guaranteed that a boolean will always be appropriate, something like this:

Compare(CaseSensitive : true);

I found this article very interesting that could solve your question. Here is an excerpt from the article.

"This is one of the worst practices. Boolean means that your role will be playing a totally different role depending on the state of just one variable. This will make our role more of a responsibility, which means that any change in function code we will have to take into account the other roles that the role is performing. "

Source: link