Boolean parameters aren't always bad. It depends on the language. This is a more superficial explanation of why they're bad: they're hard to name. I agree. Mor

Boolean parameters aren't always bad. It depends on the language. This is a more superficial explanation of why they're bad: they're hard to name. I agree. More deeply: they also scale horribly. Boolean parameters often are used to switch off to a meaningfully different function, and when they accumulate, you have 2^n different cases. At n = 6, you have two anti-patterns: a function with at least 6 parameters and probably more, and quite possibly 64 different use cases. How likely is it that those parameters all play well together? It's quite probable that there are combinations of the parameters that don't make any sense together. They also don't extend well. If you move from 2 cases to 3, the common behavior (by a maintenance programmer who doesn't understand the code well and is working to deadline, so forgive him) is to add another boolean parameter rather than refactor it to an enum or union. Then you have a "case2" and "case3" boolean parameter and get the problem described above: 4 possibilities, 1 of which is meaningless. With named, optional arguments, boolean parameters can be fine-- if you know that there will never be more than 2 cases. Sometimes they're the right thing. That said, they're a code smell (not always bad, but suggestive that you might be doing something wrong) and I'd almost never use them in Haskell, which (although a great language) doesn't have named arguments, because it's so easy to create your own datatype (that is easier to extend than a boolean).