While the ATM example was clear, it was a system, and so you may be wondering how that could possibly apply to low-level concepts, such as functions. Let's look at an example:

// PetFetcher searches the data store for pets whose name matches
// the search string.
// Limit is optional (default is 100). Offset is optional (default 0).
// sortBy is optional (default name). sortAscending is optional
func PetFetcher(search string, limit int, offset int, sortBy string, sortAscending bool) []Pet {
  return []Pet{}
}

That probably looks OK, right? The problem is that most of the usage looks like the following:

results := PetFetcher("Fido", 0, 0, "", true)

As you can see, most of the time we don't need all of those return values, and many of the inputs are ignored.

The first step to addressing this sort of situation is to look at the under-used parts of the code and ask yourself, do we really need them? If they exist only for testing, then it means they are test-induced damage, which we will look at later in this chapter.

If they exist for some infrequently used but compelling use case, then we can address it another way. The first option would be to split the function into multiple parts; this would allow users to adopt only the complexity they need. The second option is to merge the configuration into an object, allowing users to ignore the parts they don't use.

In both approaches, we are providing reasonable defaults, reducing the mental burden of the function by allowing users to only worry about what they need.