Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

PR Review: Avoid Too Many Parameters

DZone's Guide to

PR Review: Avoid Too Many Parameters

Check out two sections of code that raised some flags while the author was doing a code review and learn what you should do to fix these problems.

Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

During a code review, I ran into these two sections, which raised some flags. 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 this is that we already have parameters on the call, and eventually, you’ll get to something like this:

image

...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.

Do you pay to use your database? What if your database paid you? Learn more with RavenDB.

Topics:
performance ,parameters ,pr review

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}