PR Reviewavoid too many parameters
time to read 2 min | 228 words

During code review I run into these two sections, which raised a flag. Can you tell why?

image

image

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 that is that we already have parameters on the call, and eventually you’ll get to something like this:

image

Which is the queen of 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.

Tweet Share Share 0 comments
Tags:

More posts in "PR Review" series:

  1. (19 Dec 2017) The simple stuff will trip you
  2. (08 Nov 2017) Encapsulation stops at the assembly boundary
  3. (25 Oct 2017) It’s the error handling, again
  4. (23 Oct 2017) Beware the things you can’t see
  5. (20 Oct 2017) Code has cost, justify it
  6. (10 Aug 2017) Errors, errors and more errors
  7. (21 Jul 2017) Is your error handling required?
  8. (23 Jun 2017) avoid too many parameters
  9. (21 Jun 2017) the errors should be nurtured