

Do Not use boolean variable as function parameters - sonic0002
http://www.pixelstech.net/article/index.php?id=1335076725

======
EvilTerran
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);

------
makecheck
Enumerations or other constants are helpful but generally only if the type has
_any_ other use besides a single function call (e.g. is it a type that you'd
want to store as a field in a structure somewhere, or would it be useful in 2
or 3 other routines?). They should also be absolutely unique types (using
whatever scheme in the language would guarantee that) to avoid bugs.

An approach that is usually better is to rename the entire function, creating
two functions. To extend the article's example, this would mean having both
"widget->repaintImmediately()" and "widget->repaintLater()" (or whatever).
This can even be implemented by having both of the public routines call a
single internal routine that is still parameterized.

When the function names are different, everything you need is in one place;
you don't have to waste time figuring out where the corresponding list of
allowed values is defined. Unique functions may also require less error-
handling if only some values are allowed; e.g. if the type would include "A,
B, C" and a parameterized function wouldn't accept "C", it's easier to define
only funcA() and funcB() and just not have funcC(). Conversely, if you some
day realize you actually have more cases than you originally thought, adding a
funcD() is trivial and that decision doesn't affect anything else.

An example of constant-parameter bugs: it's common to see someone define
several unrelated values that are _effectively_ all "const int" or strings,
which allows values to be misused without warning (especially if they're named
similarly). In Cocoa, NSFontAttributeName and NSFontNameAttribute have the
same type but different uses; while this isn't a true/false case it shows how
easy it is for something to be wrong and how important a unique type can be
for debugging.

------
dalke
See also [http://mail.python.org/pipermail/python-
dev/2002-April/02210...](http://mail.python.org/pipermail/python-
dev/2002-April/022107.html)

