Clean Code: Functions with few parameters [closed]

Question

I read the first chapters of Clean Code by Robert C. Martin, and it seems to me it's pretty good, but I have a doubt, in one part it is mentioned that it is good (cognitively) that the functions should have as few parameters as possible, it even suggests that 3 or more parameters is too much for a function (which I find very exaggerated and idealistic), so I started to wonder...

Both the practices of using global variables and passing many arguments on the functions would be bad programming practices, but the use of global variables can greatly reduce the number of parameters in the functions...

So I wanted to hear what you think about it, is it worth using global variables to reduce the number of parameters of the functions or not? In what cases would it be?

What I think is that it depends on several factors:

• Source code size.
• Number of parameters in average of the functions.
• Number of functions.
• Frequency in which the same variables are used.

In my opinion if the source code size is relatively small (like less than 600 lines of code), there are many functions, the same variables are passed as parameters and the functions have many parameters, then using global variables would be worth, but I would like to know...

• Do you share my opinion?
• What do you think of other cases where the source code is bigger, etc.?

P.S. I saw this post, the titles are very similar, but he doesn't ask what I want to know.

Answer 1

I don't share your opinion. In my opinion using global variables is a worse practice than more parameters irrespective of the qualities you described. My reasoning is that more parameters may make a method more difficult to understand, but global variables can cause many problems for the code including poor testability, concurrency bugs, and tight coupling. No matter how many parameters a function has, it won't inherently have the same problems as global variables.

...the same variables are passed as parameters

It may be a design smell. If you have the same parameters being passed to most functions in your system, there may be a cross-cutting concern that should be handled by introducing a new component. I don't think passing the same variable to many functions to be sound reasoning to introduce global variables.

In one edit of your question you indicated that introducing global variables might improve the readability of code. I disagree. Usage of global variables is hidden in the implementation code whereas function parameters are declared in the signature. Functions should ideally be pure. They should only operate on their parameters and should not have any side-effects. If you have a pure function, you can reason about the function by looking just at one function. If your function is not pure, you must consider the state of other components, and it becomes much more difficult to reason about.

Answer 2

You should avoid global variables like the plague.

I wouldn't put a hard limit to number of arguments (like 3 or 4), but you do want to keep them to a minimum, if possible.

Use structs (or objects in C++) to group together variables into a single entity and pass that (by reference) to functions. Usually a function gets a structure or object (with a few different things in it) passed to it along with a couple of other parameters that tell the function to do something to the struct.

For good-smelling, clean, modular code, try to stick to the single responsibility principle. Do that with your structs (or objects), the functions, and the source files. If you do that, the natural number of parameters passed to a function will be obvious.

Answer 3

We're talking about cognitive load, not syntax. So the question is... What is a parameter in this context?

A parameter is a value which affects the behaviour of the function. The more parameters, the more possible combinations of values you get, the harder reasoning about the function gets.

In that sense, global variables that the function uses are parameters. They're parameters that don't appear in its signature, that have order-of-construction, access control and remanence issues.

Unless said parameter is what is called a cross-cutting concern, that is some program-wide state which everything uses but nothing alters (e.g. a logging object), you should not replace function parameters with global variables. They'd still be parameters, but nastier.

Answer 4

Having many parameters is considered undesirable, but turning them into fields or global variables is a lot worse because it doesn't solve the actual problem but introduce new problems.

Having many parameters is not in itself the problem, but it is an symptom that you might have a problem. Consider this method:

Graphics.PaintRectangle(left, top, length, height, red, green, blue, transparency);

Having 7 parameters is a definite warning sign. The underling problem is these parameters are not independent but belongs in groups. left and top belong together as a Position-structure, length and height as a Size structure, and red, blue and green as a Color structure. And maybe Color and transparency belongs in a Brush structure? Perhaps Position and Size belongs together in a Rectangle structure, in which case we may even consider turning it into a Paint method on the Rectangle object instead? So we may end up with:

Rectangle.Paint(brush);

Mission accomplished! But the important thing is we actually have improved the overall design, and the reduction in number of parameters is a consequence of this. If we just reduce the number of parameter without tackling the underlying issues, we might do something like this:

Graphics.left = something;
Graphics.top = something;
Graphics.length = something;
...etc
Graphics.PaintRectangle();

Here we have achieved the same reduction in number of parameter, but we have actually made the design worse.

Bottom line: For any programming advice and rules-of-thumb it is really important to understand the underlying reasoning.

Answer 5

IMHO your question is based on a misunderstanding. In "Clean Code", Bob Martin does not suggest to replace repeated function parameters by globals, that would be a really awful advice. He suggest to replace them by by private member variables of the class of the function. And he also proposes small, cohesive classes (typically smaller than the 600 lines of code you mentioned), so these member variables are definitely no globals.

So when you have the opinion in a context with less than 600 lines "using global variables would be worth it", then you perfectly share the opinion of Uncle Bob. Of course, it is debatable if "3 parameters at maximum" is the ideal number, and if this rule sometimes leads to too many member variables even in small classes. IMHO this is a trade-off, there is no hard-and-fast rule where to draw the line.

Answer 6

is it worth using global variables to reduce the number of parameters of the functions or not?

Not

I read the first chapters of this book

Did you read the rest of the book?

A global is just a hidden parameter. They cause a different pain. But it's still pain. Stop thinking of ways to get around this rule. Think about how to follow it.

What is a parameter?

It's stuff. In a nicely labeled box. Why does it matter how many boxes you have when you can put whatever stuff in it?

It's the cost of shipping and handling.

Move(1, 2, 3, 4)

Tell me you can read that. Go on, try.

Move(PointA, PointB)

That's why.

That trick is called introduce parameter object.

And yes it's just a trick if all you're doing is counting parameters. What you should be counting is IDEAS! Abstractions! How much are you making me think about at once? Keep it simple.

Now this is the same count:

Move(xyx, y)

OW! That's horrible! What went wrong here?

It's not enough to limit the number of ideas. They must be clear ideas. What the heck is a xyx?

Now this is still weak. What's a more powerful way to think about this?

Functions should be small. No smaller than that.

Uncle Bob

Move(PointB)

Why make the function do any more than it really needs to do? The single responsibility principle isn't only for classes. Seriously, it's worth changing an entire architecture just to stop one function from turning into an overloaded nightmare with 10 sometimes related parameters some of which can't be used with others.

I've seen code where the most common number of lines in a function was 1. Seriously. I'm not saying you have to write that way but sheesh, don't tell me a global is the ONLY way you can comply with this rule. Stop trying to get out of refactoring that function properly. You know you can. It might break down into a few functions. It might actually turn into a few objects. Hell you might even break part of it out into an entirely different application.

The book isn't telling you to count your parameters. It's telling you to pay attention to the pain you're causing. Anything that fixes the pain fixes the problem. Just be aware when you're simply trading one pain for another.

Answer 7

I would never use global variables to reduce parameters. The reason is that global variables can be altered by any function/command, therefore making the function input unreliable and prone to values that are out of scope of what the function can handle. What if the variable was changed during the execution of the function and half the function had different values than the other half?

Passing parameters on the other hand, restricts the variable's scope to only its own function such that only the function can modify a parameter once its called.

If you need to pass global variables instead of a parameter, its preferable to redesign the code.

Just my two cents.

Answer 8

I'm with Uncle Bob on this and agree that more than 3 params is something to be avoided (I very rarely use more than 3 params in a function). Having lots of params on a single function creates a bigger maintenance problem and is probably a smell that your function is doing too much/has too many responsibilities.

If you are using more than 3 in a method in a OO language then you should consider are the params not related to each other in some way and therefore you should really be passing in an object instead?

Also, if you create more (smaller) functions you'll also notice that functions tend to more often have 3 params or less. Extract function/method is your friend :-).

Do not use global variables as a way to get round having more params! That is swapping one bad practice for an even worse one!

Answer 9

A valid alternative to many function parameters is to introduce a parameter object. This is useful if you have a composed method which passes (almost) all of its parameters to a bunch of other methods.

In simple cases this is a simple DTO having nothing but the old parameters as properties.

Answer 10

Using global variables always seems an easy way to code (especially in a small program), but it will make your code difficult to extend.

Yes, you can reduce the number of parameters in a function by using an array to bind the parameters in one entity.

function <functionname>(var1,var2,var3,var4.....var(n)){}

The above function will be edited and changed to [using associative array]-

data=array(var1->var1,
           var2->var2
           var3->var3..
           .....
           ); // data is an associative array

function <functionname>(data)

I agree with robert bristow-johnson’s answer: you can even use a struct to bind data in a single entity.

Answer 11

Taking an example from PHP 4, look at the function signature for mktime():

• int mktime ([ int $hour = date("H") [, int $minute = date("i") [, int $second = date("s") [, int $month = date("n") [, int $day = date("j") [, int $year = date("Y") [, int $is_dst = -1 ]]]]]]] )

Don't you find that confusing? The function is called "make time" but it takes day, month and year parameters as well as three time parameters. How easy is it to remember which order they go in? What if you see mktime(1, 2, 3, 4, 5, 2246);? Can you understand that without having to refer to anything else? Is 2246 interpreted as a 24-hour time "22:46"? What do the other parameters mean? It would be better as an object.

Moving to PHP 5, there now is a DateTime object. Amongst its methods are two called setDate() and setTime(). Their signatures are as follows:

• public DateTime setDate ( int $year , int $month , int $day )
• public DateTime setTime ( int $hour , int $minute [, int $second = 0 ] )

You still have to remember that the order of the parameters goes from greatest to smallest, but it's a big improvement. Note that there isn't a single method that allows you to set all six parameters at once. You have to make two separate calls to do this.

What Uncle Bob is talking about is avoiding having a flat structure. Related parameters should be grouped together into an object, and if you have more than three parameters, it's very likely you've got a pseudo object there, which gives you the opportunity of creating an appropriate object for greater separation. Although PHP doesn't have a separate Date and Time class, you could consider that DateTime really contains a Date object and a Time object.

You could possibly have the following structure:

<?php
$my_date = new Date;
$my_date->setDay(5);
$my_date->setMonth(4);
$my_date->setYear(2246);

$my_time = new Time;
$my_time->setHour(1);
$my_time->setMinute(2);
$my_time->setSecond(3);

$my_date_time = new DateTime;
$my_date_time->setTime($my_time);
$my_date_time->setDate($my_date);
?>

Is it mandatory to set two or three parameters each time? If you want to change just the hour or just the day, it's now easy to do so. Yes, the object needs to be validated to make sure each parameter works with the others, but that was the case before anyway.

The most important thing is, is it easier to understand, and therefore maintain? The code block at the bottom is bigger than a single mktime() function, but I'd argue that's much easier to understand; even a non-programmer wouldn't have much trouble working out what it does. The goal is not always shorter code or cleverer code, but more maintainable code.

Oh, and don't use globals!

Answer 12

Lots of good answers here yet most are not addressing the point. Why these rules of thumb? It is about scope, it is about dependencies and it is about proper modelling.

Globals for arguments is worse because it only looks like you made it simpler but in fact you only hid the complexity. You don't see it anymore in the prototype but you still have to be aware of it (which is hard since it is not there for you to see anymore) and getting your head around the function's logic won't help you because there may be other hidden logic interfering behind your back. Your scope went all over the place and you introduced a dependency on whatever because whatever can now mess with your variable. Not good.

The main thing to maintain for a function is that you can understand what it does by looking at the prototype and call. So the name should be clear and unambiguous. But also, the more arguments there are the harder it will be to grasp what it does. It widens the scope in your head, too many things going on, this is why you want to limit the number. It matters what kind of arguments you are dealing with though, some are worse than others. An extra optional boolean that allows for case insensitive processing does not nake the function any harder to understand so you would not want to make a big deal about it. As a side note, enums make better arguments than booleans because an enum's meaning is obvious in the call.

The typical trouble is not that you write a new function with an enormous amount of arguments, you will start with only a few when you do not realize yet how complex the problem you are solving really is. As your program evolves, argument lists gradually tend to get longer. Once a model has set in your mind you want to keep it because it is a safe reference that you know. But in retrospect the model may not be that great. You missed a step or too in the logic and you failed to recognize an entity or two. "OK... I could start over and spend a day or two refactoring my code or... I could add this argument so I can make it do the right thing after all and be done with it. For now. For this scenario. To get this bug off my plate so I can move the sticky note to done."

The more often you go with the second solution the more expensive further maintenance is going to be and the harder and unattractive a refactor will become.

There is no boiler plate solution for reducing the number of arguments in an existing function. Just grouping them into compounds is not really making things easier, it is just another way of wiping complexity under the carpet. Doing it right involves looking at the entire call stack again and recognizing what is missing or has been done wrong.

Answer 13

Several times I have found that grouping a lot of parameters that were sent together improved things.

• It forces you to give a good name to this agrupation of concepts that are used together. If you use those parameters together it could be that they have a relationship (or that you should not use together at all).

• Once with the object I usually find that some funtionality can be moved that this apparently stuypid object. It is usually easy to test and with great cohesion and low coupling making thing even better.

• The next time I need to add a new parameter I have a nice place to include it without changing the signature of a lot of methods.

So it may not work 100% of the times but ask yourself if this list of parameter should be grouped in an object. And please. Do not use untyped classes like Tuple to avoid creating the object. You are using object-oriented programming, do not mind to create more objects if you need them.

Answer 14

With all due respect, I'm pretty sure you've completely missed the point of having a small number of parameters in a function.

The idea is that the brain can only hold so much "active information" at one time, and if you have n parameters in a function, you have n more pieces of "active information" that needs to be in your brain to easily and accurately comprehend what the piece of code is doing (Steve McConnell, in Code Complete (a much better book, IMO), says something similar about 7 variables in a method's body: rarely do we reach that, but any more and you're losing the ability keep everything straight in your head).

The point of a low number of variables is to be able to keep the cognitive requirements of working with this code small, so you can work at it (or read it) more effectively. A side cause of this is that well factored code will tend to have less and less parameters (e.g., poorly factored code tends to group a bunch of stuff into a mess).

By passing objects instead of values, perhaps you gain a level of abstraction for your brain because now it needs to realize yes, I've got a SearchContext to work with here instead of thinking about the 15 properties that might be within that search context.

By attempting to use Global variables, you've completely gone in the entire wrong direction. Now not only have you not solved the problems of having too many parameters for a function, you've taken that problem and thrown it in a much, much better problem that you now have to carry around in your mind!

Now instead of working just at the function level, you need to be considering the global scope of your project as well (gawd, how terrible! I shudder...). You don't even have all your information in front of you in the function (crap, what's that global variable name?) (I hope this hasn't been changed by something else since I called this function).

Globally scoped variables are one of the very worst things to see in a project (large or small). They denote a disability for proper scope management, which is a highly fundamental skill for programming. They. Are. Evil.

By moving parameters out of your function and putting them into globals, you've shot yourself in the foor (or the leg, or face). And God forbid you ever decide that hey, I can re-use this global for something else... my mind trembles at the thought.

The whole ideal is to keep things easy to manage, and global variables are NOT going to do that. I'd go so far as to say they're one of the worst things you can do to go in the opposite direction.

Answer 15

I’ve found a highly effective approach (in JavaScript) to minimize friction between interfaces: Use a uniform interface for all modules, specifically: single param functions.

When you need multiple parameters: Use a single Object/Hash or Array.

Bear with me, I promise I’m not trolling...

Before you say “what good is a single param func?” or “Is there a difference between 1 Array and multi arg funcs?”

Well, yes. It's perhaps visually subtle, but the difference is manyfold – I explore the many benefits here

Apparently some ppl think 3 is the right # of arguments. Some think it's 2. Well, that still begs the question, "which param goes in arg[0]?" Instead of picking the option which constrains the interface with a more rigid declaration.

I guess I argue for a more radical position: don’t rely on positional arguments. I just feel it’s fragile and leads to arguments about the position of the damn arguments. Skip it and move right along to the inevitable fighting about the names of functions and variables. 😉

Seriously though, after naming settles, hopefully you end up with code like follows, which is somewhat self documenting, not position-sensitive, and allows future param changes to be handled inside to the function:

function sendMessage({toUser, fromUser, subject, body}) { }

// And call the method like so:
sendMessage({toUser: this.parentUser, fromUser: this.currentUser, subject: ‘Example Alert’})

---