PR Review: Avoid Too Many Parameters

During a code review, I ran into these two sections, which raised some flags. Can you tell why?

The problem with this type of code is two-fold. First, we add optional parameters to reduce the number of breaking changes we have. The problem with this is that we already have parameters on the call, and eventually, you’ll get to something like this:

...which is the queen of the optional parameters method, and you can probably guess how it looks internally.

In the first case, we can add the new optional parameter to the options variable that we are already sending this method. This way, we don’t have to worry about breaking changes, and we already have a way to setup options, determine defaults, etc.

In the second case, we are passing two bools to the method, and there isn’t a preexisting parameters object. Instead of creating one, we can use a Flags enum, whose bits we can set to determine what exactly the behavior of this method should be. That is generally much easier to maintain in the long run.