Return to Answer

Boolean arguments are very hard to read, and thus difficult to maintain. The main problem is that the purpose is generally clear when you read the method signature where the argument is named. However, naming a parameter is generally not required in most languages. So you will have anti-patterns like RSACryptoServiceProvider#encrypt(Byte[], Boolean) where the call determines what kind of encryption is to be used.

where the reader has to lookup the method's signature simply to determine what the hell true could actually means. Passing an integer is of course just as bad:

would tell you just as much (or rather: just as little). Even if you define constants to be used for the integer then users of the function may simply ignore them and keep using literal values.

Booleans can only have two values. This means that if you have a third option, then you'd have to refactor your signature. Generally this cannot be done because of backwards compatibility, so you'd have to extend any public class with another public method. This is what Microsoft finally did when they introduced RSACryptoServiceProvider#encrypt(Byte[], RSAEncryptionPadding) where they used an enumeration (or at least a class mimicking an enumeration) instead of a boolean.

It may even be easier to use a full object or interface as parameter, in case the parameter itself needs to be parameterized. In the above example you could imagine that you would have an OAEP padding parameter that itself can be configured with the hash value to use. Note that there are now 6 SHA-2 hash algorithms and 4 SHA-3 hash algorithms, so the number of enumeration values may explode if you only use a single enum as above (this is possibly the next thing Microsoft is going to find out).

Boolean parameters may also indicate that the method or class is not designed well. For instance, about every other cryptographic library doesn't use a padding flag in the method signature at all.

Determining the padding is something that is performed during creation or initialization of the class instance. That way the code can fail before a padding algorithm is chosen. For instance, many RSA keys on smart cards only support one of the two padding mechanisms. So you could create the provider and only find out that the mechanism is not supported when you'd perform the actual encryption or decryption. The underlying philosophy is called fail-fast.

Almost all software gurus that I like warn against boolean arguments. For instance, Joshua Bloch warns against them in the highly appreciated book "Effective Java". In general they should simply not be used. You could argue that they could be used if the case that there is one parameter that is easy to understand. But even then: Bit.set(Boolean) is probably better implemented using two methods: Bit.set() and Bit.unset().

Boolean arguments are very hard to read, and thus difficult to maintain. The main problem is that the purpose is generally clear when you read the method signature where the argument is named. However, naming a parameter is generally not required in most languages. So you will have anti-patterns like RSACryptoServiceProvider#encrypt(Byte[], Boolean) where the boolean parameter determines what kind of encryption is to be used in the function.

where the reader has to lookup the method's signature simply to determine what the hell true could actually mean. Passing an integer is of course just as bad:

would tell you just as much - or rather: just as little. Even if you define constants to be used for the integer then users of the function may simply ignore them and keep using literal values.

Booleans can only have two values. This means that if you have a third option, then you'd have to refactor your signature. Generally this cannot be easily performed if backwards compatibility is an issue, so you'd have to extend any public class with another public method. This is what Microsoft finally did when they introduced RSACryptoServiceProvider#encrypt(Byte[], RSAEncryptionPadding) where they used an enumeration (or at least a class mimicking an enumeration) instead of a boolean.

It may even be easier to use a full object or interface as parameter, in case the parameter itself needs to be parameterized. In the above example OAEP padding itself could be parameterized with the hash value to use internally. Note that there are now 6 SHA-2 hash algorithms and 4 SHA-3 hash algorithms, so the number of enumeration values may explode if you only use a single enumeration rather than parameters (this is possibly the next thing Microsoft is going to find out).

Boolean parameters may also indicate that the method or class is not designed well. As with the example above: any cryptographic library other than the .NET one doesn't use a padding flag in the method signature at all.

Almost all software gurus that I like warn against boolean arguments. For instance, Joshua Bloch warns against them in the highly appreciated book "Effective Java". In general they should simply not be used. You could argue that they could be used if the case that there is one parameter that is easy to understand. But even then: Bit.set(boolean) is probably better implemented using two methods: Bit.set() and Bit.unset().

And this brings into view the other major issue. If you need to call many methods using the same parameter then the entire design may not be correct. It seems that the boolean is used to configure the system rather than to parameterize the method. There are many ways of configuring a system, for instance using the State design pattern which defines a context. Contexts are also often used as structures within non-object oriented languages. For instance, OpenSSL uses many context for specific cryptographic operations.

Other design patterns that could be used are the Decorator pattern and the Facade pattern and even the Strategy pattern (which I introduce reluctantly into the mix). Which one to use is of course hidden in the art of software design.

A horrible use of booleans would be to enable / disable the use of other parameters or otherwise change the meaning of the method signature. In that case you should replace them by an optional argument or an Optional template class - depending on which language you're using.

Almost all software gurus that I like warn against boolean arguments. For instance, Joshua Bloch warns against them in the highly appreciated book "Effective Java". In general they should simply not be used. You could argue that they could be used if the case that there is one parameter that is easy to understand. But even then: Bit.set(Boolean) is probably better implemented using two methods: Bit.set() and Bit.unset().

Almost all software gurus that I like warn against boolean arguments. For instance, Joshua Bloch warns against them in the highly appreciated book "Effective Java". In general they should simply not be used. You could argue that they could be used if the case that there is one parameter that is easy to understand. But even then: Bit.set(Boolean) is probably better implemented using two methods: Bit.set() and Bit.unset().

Far TL;DR: don't use boolean arguments.

TL;DR: don't use boolean arguments.