TL;DR: don't use boolean arguments.
See below why they are bad, and how to replace them (in bold face).
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.
So you will get a call like:
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.
The best way to solve this is to use an enumeration. If you have to pass an enum
RSAPadding with two values:
PKCS1_V1_5 then you would immediately be able to read the code:
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:
If you cannot directly refactor the code you could define constants to at least make them more readable:
const boolean ENCRYPT = true;
const boolean DECRYPT = false;
is much more readable than:
even if you'd rather have: