3 ms·

Do Not use boolean variable as function parameters

3 points by sonic0002 14y ago

dalke 14y ago
See also http://mail.python.org/pipermail/python-dev/2002-April/022107.html http://mail.python.org/pipermail/python-dev/2002-April/02210...
EvilTerran 14y ago
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 14y ago
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.

3 points by sonic0002 14y ago

dalke 14y ago

See also http://mail.python.org/pipermail/python-dev/2002-April/022107.html http://mail.python.org/pipermail/python-dev/2002-April/02210...

EvilTerran 14y ago

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 14y ago

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.