3 ms·

I really don't find that convincing at all. Default arguments are one of the most effective ways of removing boilerplate and making code easier to read and writ

I really don't find that convincing at all. Default arguments are one of the most effective ways of removing boilerplate and making code easier to read and write. Bad programmers will be bad programmers no matter what, and copy/pasted code that the coder doesn't understand will be fragile or broken no matter what. The problem with this reasoning is contained in this: > to force programmers to consider the API and the values they are passing for each argument rather than silently accepting defaults they may not be aware of. All you will force poor coders to do will be to fudge the arguments until the code "works". This is actually worse than the default arguments scenario, because the defaults are more likely to be acceptable than the first value the coder stumbles upon that makes the function go.

haberman 15y ago
For me it has nothing to do with bad programmers. It has to do with not having "hidden" input to a function. For example, consider a parsing function that has a boolean parameter indicating whether the parsing is "strict" or not. If you make this parameter have a default, it would be easy to use this function (or read code that uses it) without even realizing that the function can operate in more than one "mode." There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site! Taking a line from the Python philosophy: "explicit is better than implicit."
- ajross 15y ago
  C++ is filled with hidden input. The identity of the this pointer is hidden from the execution of the function. The identity of the function to be executed is hidden from the caller. If that's really your requirement, then you're using the wrong language, the ship sailed. I agree with mistercow: default arguments are, on the whole, a Good Thing. Think of them as a restricted form of overloading which requires (much!) less code to be written. Obviously they can be misused, but again, that's the nature of programming (and especially of C++). Sane default argument conventions make code easier to read and write.
  - haberman 15y ago
    > The identity of the this pointer is hidden from the execution of the function. Your argument makes no sense; the "this" pointer is just a function parameter, and the whole point of a function is that the arguments aren't fixed until the function is called. No part of this is implicit. > The identity of the function to be executed is hidden from the caller. The function is named at the call site along with all input to that function (unless you use default arguments). This also is not hiding: every part of the function and its input is explicit. Much better arguments for your case would be overloaded operators and implicit conversions, both of which happen without an explicit information at the call site. But it's no coincidence that both of these are forbidden by the Google Style Guide also.
- mistercow 15y ago
  > If you make this parameter have a default, it would be easy to use this function (or read code that uses it) without even realizing that the function can operate in more than one "mode." So? I don't understand what the problem is. The very act of packaging code in a function is one that hides information about what that function does. And suppose you don't provide a default for the `strict` argument. Unless you're using a language with named function arguments (or an approximation thereof like Objective-C), you won't know that the `false` you see in the argument list means "don't use strict" anyway until you read the documentation. And once you're reading the documentation, this all becomes moot. > There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site! Yeah, and if you reorder your function parameters, or rename your function, or change the "strict" argument to "lax", or an infinite number of other changes, you would also change behavior with no change at the call site. The solution in each case is "don't do that". Again, the act of packaging code in a function is one that makes it so that changes in behavior can happen independent of the call site. Sometimes it works to your advantage. Sometimes it doesn't. That's just life.
  - haberman 15y ago
    > 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.
- masklinn 15y ago
  > It has to do with not having "hidden" input to a function. Why would it be hidden? It's a default, customizable behavior. If you don't need to customize it you don't and there's no reason to task you with putting the method in the state which is going to be needed 9 times out of 10. > and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site! And if the whole implementation is replaced by formatting your hard drive, the caller could change behavior with no code change at the call site!! > Taking a line from the Python philosophy: "explicit is better than implicit." You're probably misapplying/misunderstanding things, since Python is one of the languages making the most use out of default values and with extremely strong first-class support for them.

haberman 15y ago

For me it has nothing to do with bad programmers. It has to do with not having "hidden" input to a function. For example, consider a parsing function that has a boolean parameter indicating whether the parsing is "strict" or not. If you make this parameter have a default, it would be easy to use this function (or read code that uses it) without even realizing that the function can operate in more than one "mode." There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site! Taking a line from the Python philosophy: "explicit is better than implicit."

ajross 15y ago
C++ is filled with hidden input. The identity of the this pointer is hidden from the execution of the function. The identity of the function to be executed is hidden from the caller. If that's really your requirement, then you're using the wrong language, the ship sailed. I agree with mistercow: default arguments are, on the whole, a Good Thing. Think of them as a restricted form of overloading which requires (much!) less code to be written. Obviously they can be misused, but again, that's the nature of programming (and especially of C++). Sane default argument conventions make code easier to read and write.
- haberman 15y ago
  > The identity of the this pointer is hidden from the execution of the function. Your argument makes no sense; the "this" pointer is just a function parameter, and the whole point of a function is that the arguments aren't fixed until the function is called. No part of this is implicit. > The identity of the function to be executed is hidden from the caller. The function is named at the call site along with all input to that function (unless you use default arguments). This also is not hiding: every part of the function and its input is explicit. Much better arguments for your case would be overloaded operators and implicit conversions, both of which happen without an explicit information at the call site. But it's no coincidence that both of these are forbidden by the Google Style Guide also.
mistercow 15y ago
> If you make this parameter have a default, it would be easy to use this function (or read code that uses it) without even realizing that the function can operate in more than one "mode." So? I don't understand what the problem is. The very act of packaging code in a function is one that hides information about what that function does. And suppose you don't provide a default for the `strict` argument. Unless you're using a language with named function arguments (or an approximation thereof like Objective-C), you won't know that the `false` you see in the argument list means "don't use strict" anyway until you read the documentation. And once you're reading the documentation, this all becomes moot. > There is no indication at the call site what mode it is operating in, and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site! Yeah, and if you reorder your function parameters, or rename your function, or change the "strict" argument to "lax", or an infinite number of other changes, you would also change behavior with no change at the call site. The solution in each case is "don't do that". Again, the act of packaging code in a function is one that makes it so that changes in behavior can happen independent of the call site. Sometimes it works to your advantage. Sometimes it doesn't. That's just life.
- haberman 15y ago
  > 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.
masklinn 15y ago
> It has to do with not having "hidden" input to a function. Why would it be hidden? It's a default, customizable behavior. If you don't need to customize it you don't and there's no reason to task you with putting the method in the state which is going to be needed 9 times out of 10. > and indeed if the default value is flipped in the header file the caller could change behavior with no code change at the call site! And if the whole implementation is replaced by formatting your hard drive, the caller could change behavior with no code change at the call site!! > Taking a line from the Python philosophy: "explicit is better than implicit." You're probably misapplying/misunderstanding things, since Python is one of the languages making the most use out of default values and with extremely strong first-class support for them.