Software Design/Don't add a parameter that won't be used

From Wikiversity
Jump to navigation Jump to search

Checklist questions:

  • Somebody would ever want to change the function parameter's value?
  • Somebody would ever want to change the class parameter's value?
  • Somebody would ever want to change the configuration parameter's value?

Before adding a new parameter to a function or a class, or a new configuration parameter, ask yourself if any user of the function, or the class, or the software would ever need or want to change the default value to something else. If the answer is "No" or "Very unlikely", hardcode the default value and avoid the complexity of a parameter.

Why[edit | edit source]

An extra parameter to a function or a class contributes to their size. To provide an option to not specify the extra parameter for a function there should be an overloading or an additional function with a different name. To provide an option to not specify the extra parameter for a class the latter needs to have an additional constructor, or an additional static factory function, or an additional function in the builder. These solutions increase the API size.

On the other hand, if a function or a class doesn't provide an option to omit the extra parameter there is an opportunity for the API users to make a mistake by providing a wrong value, or confusing several parameters which have the same type.

Regarding configuration, even if an extra parameter doesn't contribute to the complexity and the size of the codebase much (or it's not perceived as a problem), when software has more configuration parameters it's harder to learn and make sense of them for new users. A lot of unimportant parameters may draw the attention of users and operators away from the few important ones or may make harder to find the important parameters.

When there are many configuration parameters, it's hard to test all of them. Some untested combinations of values for different parameters may lead to degraded performance or errors. In other words, the software is less reliable.

Why not[edit | edit source]

Related practices[edit | edit source]

References[edit | edit source]