Day 18 - Investigate long parameter lists

Do a search through your project for long parameter lists, where long is defined as more than three parameters.

Due to long parameter lists often being line-wrapped, you’ll likely have to do some manual searching, but here’s a naive regex that will find single-line method calls (in Ruby, at least) with at least four parameters:


You’ll probably find that many of your long parameter lists appear when calling library or framework code.

However, you might find some in your own code. If you do, it doesn’t necessarily mean there’s anything wrong, but it’s worth asking yourself a few questions about them:

  1. Should any of the data that you’re passing in be instance data instead? A clear indication this is true is if other methods on this object also require the same parameter.

  2. Do you frequently pass several of these parameters together? If so, it’s possible you have a Data Clump and could benefit from extracting a value object to contain them.

  3. Are any of these parameters booleans? If so, you probably have a case of control coupling, and would do well to remove it.

  4. Can any of these parameters be removed outright? You’d be surprised how easy it is to continue passing something into a method that no longer requires it.

By the way, the above questions are worth asking about just about any list of parameters, so consider them even if you tend to keep your parameter lists short.

Good luck!

Solid advice about checking for passing booleans. I can’t find any particularly gnarly parameter lists in our codebase fortunately, but I nearly introduced a boolean flag today as a parameter and instead decided for two different functions because of this.

This one ended up being a learning exercise for me about Python’s support for data clump like classes via namedtuples, the new Data Class feature in 3.7, and the attrs module.

No code change in the 20 mins, but a lot of learning that will be useful in the future. Time well spent!

Love the attrs module - hadn’t heard about the data class feature - looks pretty slick but I’m still writing Python 2.7 code on my primary client. Python 3 upgrade is in progress though.

1 Like

Time to make the switch if you can, Python 3 (particularly 3.5/3.6) are a dramatic improvement. I was in 2.7 for a long time, but once I got to 3 about a year ago I haven’t looked back.