The Evil of Optional Parameters: When Having too Many Options is Self Destructing

The article discusses the negative impact of using optional parameters in a function, specifically in the context of an AI agent management system called agents.com. Initially, a simple function named getAgentSkills was created to return a list of skills associated with an agent. As the application evolved, more features were added, leading to an increasingly complex function signature with multiple optional parameters.

The article highlights several issues arising from the use of optional parameters. First, it allows for contradictory and impossible states to be returned, as seen when passing both includeAgent=true and deletedAt=Date(SOME_DATE). This ambiguity confuses developers and makes it difficult to predict the function's output.

Second, optional parameters lead to defensive code on the part of consumers, who must write additional logic to determine what response they are receiving. This not only increases code complexity but also makes the codebase harder to maintain.

Lastly, the article argues that optional parameters create a burden for developers, as they need to remember the correct combination of optional parameters to achieve the desired functionality. The example provided shows a lengthy function call with multiple boolean values and an undefined placeholder, which is considered an inefficient and unclean way to consume the API.

The author concludes that while there are rare cases where optional parameters might be justified, such as when working with a heavily cached system, the use of optional parameters in this particular function has led to a tangled and confusing API that negatively impacts the development experience for all involved.