I'd say "don't use booleans as positional parameters" for the reasons the article discusses - as it's completely non-self-documenting. Take one of the examples:

I'd say "don't use booleans as positional parameters" for the reasons the article discusses - as it's completely non-self-documenting. Take one of the examples: str.replace("%USER%", user, false); ... where it transpires the last parameter is case sensitivity. The article's suggestion of using enumerations (or algebraic types) would be an improvement in languages that make that easy, sure: enum CaseSensitivity { CaseInsensitive, CaseSensitive } ... str.replace("%USER%", user, CaseInsensitive); ... but introducing types that are conceptually booleans seems like a contrived way to self-document. Named parameters would be preferable to either, IMO: str.replace("%USER%", user, case_sensitive = false);