> The very act of packaging code in a function is one that hides information about what that function does.
"What a function does" is encapsulated in that function's name. So for example you could have:
GoToTheStore();
If you want to make a function more generic, you can make some aspects of the function's behavior depend on arguments. So an equivalent call of a more generic function could look like:
Go(store);
Both of these are equally explicit; the first has its behavior fully specified by the function itself, the second has its behavior fully specified by a combination of the function name and its argument.
Once you have default parameters, the behavior of the function is no longer fully explicit, because some of the function's input comes from somewhere else:
Go(); // Goes to the store by default.
This is both unnecessary (both of the previous options are very usable alternatives) and needlessly implicit. It makes program logic more difficult to follow because you need to be aware of the implicit defaults to fully understand the data flow.
Also, code itself is the most reliable documentation, but looking at the implementations of the functions involved won't reveal this extra input; only cross-referencing the header files will, which requires more mental effort for your reader.
> "What a function does" is encapsulated in that function's name.
I would like to suggest that the function's name should tell you the result (going to the store) and not have anything to do with what the function does (walk, bike, drive, fly) to get that result. Parameters could restrict how the function gets the result. In which case, a default parameter of ANY means no restriction and makes perfect sense with actually less mental effort for the reader.
GoToTheStore(); /* get me to the store */
vs
GoToTheStore(ANY); /* does ANY refer to any store? */
but when necessary
GoToTheStore(DRIVE); /* I'm feeling lazy, and don't want to walk. */
"What a function does" is encapsulated in that function's name. So for example you could have:
If you want to make a function more generic, you can make some aspects of the function's behavior depend on arguments. So an equivalent call of a more generic function could look like: Both of these are equally explicit; the first has its behavior fully specified by the function itself, the second has its behavior fully specified by a combination of the function name and its argument.Once you have default parameters, the behavior of the function is no longer fully explicit, because some of the function's input comes from somewhere else:
This is both unnecessary (both of the previous options are very usable alternatives) and needlessly implicit. It makes program logic more difficult to follow because you need to be aware of the implicit defaults to fully understand the data flow.Also, code itself is the most reliable documentation, but looking at the implementations of the functions involved won't reveal this extra input; only cross-referencing the header files will, which requires more mental effort for your reader.