PR Review: Avoid Too Many Parameters
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.
Join the DZone community and get the full member experience.
Join For FreeRavenDB 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?
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.
Do you pay to use your database? What if your database paid you? Learn more with RavenDB.
Like This Article? Read More From DZone
Published at DZone with permission of Oren Eini, CEO RavenDB , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}