More and more I believe that booleans as part of parameters, whether to methods or Web APIs, are just a bad idea.

The problems I see are: most "booleans" do not have an easy to understand meaning for both True and False. For example, "ignoreLeadingAndTrailingWhitespace" is confusing when it's False: what does it mean to _not_ ignore it? Keep it? Pay attention to it?

Better _might_ be:

trimLeadingAndTrailingWhitespace

where it's clear what True means, and easier to understand when it's False (presumably "leave it as-is").

Best would be:

whitespace = REMOVE_LEADING_AND_TRAILING
and
KEEP_LEADING_AND_TRAILING

which could then lead to previously unavailable options, without requiring another parameter to be introduced:

whitespace=REMOVE_LEADING_KEEP_TRAILING

So even when it's readable when both True and False, much better is defining explicitly what those options are.

#DownWithBooleans #BooForBooleans

@jitterted Interesting. Recently we were asked to implement a feature and we added a boolean COLLECT_LOGS. When we showed it to the user she found it confusing (like in your example, she wasn’t sure what the difference between true and false was) and suggested presenting a list of two values instead (COLLECT_FULL_LOGS, GET_COUNT_ONLY). The flexibility of having the possibility to add more options in the future by using a list instead of a boolean is also very nice.
@jitterted I also think that removing any ambiguity and possible wrong interpretation super important.
And using enumeration expressing the desired goal is so much more explicit!