One function argument or instance variable [Clean Code book]

Question

Hi everyone, I'm reading Uncle Bob's "Clean Code" book and constantly finding contradictory statements. Here is one of them. Book claims that we should use as few function arguments as possible, so it's more preferably to use function without any arguments to function with one argument and after this claiming there is suggestion how to rewrite your code: make argument an instance variable. (actually I don't agree with this) Anyway, after some pages there is a section titled "Have no side effects".

Now I'm a little bit confusing: if we're making our argument an instance variable, we're going to have side effects in our functions, but "more readable" function calls. I think that seeing from function call what entities it will operate is more important than having more readable call.

What do you think about it? Thank you.

Answer 1

Personally, I would try to minimise the number of arguments in a call.

As well as readability benefits (and the risk of errors) there is a performance issue.

Each argument has to be pushed onto a stack and pulled off again so, unless the value changes with each call there is a clear benefit to having it as an instance variable accessed via a property.

Provided the code is well documented anyone calling the function should be aware that it is dependant on a particular property (or set of properties).

I usually include this sort of information in a comment block above the function definition which VS helpfully shows anyone via intellisense when they try to use my function.

Just my thoughts, I'm sure there are other views out there.

Answer 2

Book claims that we should use as few function arguments as possible, so it's more preferably to use function without any arguments to function with one argument and after this claiming there is suggestion how to rewrite your code: make argument an instance variable. (actually I don't agree with this) Anyway, after some pages there is a section titled "Have no side effects".

These are certainly opposing forces, but the two pieces of advice can both make sense if you consider Command-Query Separation. By this principle, it's preferable to have a method either mutate data or return a value, but not do both. So those fields you create to get rid of parameters are changed by mutating methods, but the "query" functions should indeed have no side effects.

Answer 3

I do not worry about the number of arguments in a call. Generally, if it "seems to long" (e.g. becomes unwieldy to use) then I see a case to re-factor it: but this comes not from a number in a book book, but rather an "it smells bad" feeling I get with the code. This doesn't necessarily make the function-calls "more readable" (the name is the same, and with good formatting -- and a sane number of arguments -- the number of arguments to a function call should not make it "harder to read").

However, except where state is required and beneficial, I try to minimize state; even if this means passing in an extra parameter or two. (Let me say that again: I favor a minimized use of [shared] state because I find that it makes programming easier as I have to worry about less side-effects. Carrying 'values through' as part of an expression/operation can often simplify a number of tasks, but see below.)

Depending upon the language paradigm (and language tools available) the methods of re-factoring and/or "acceptable" amounts of state may differ. Generally in a high-level language there is some form of method to "wrap" arguments into a better data-type or utilize some form or overloading (but only judiciously so!) or default parameters. Unfortunately, some languages simply lack sufficient high-level constructs and more compromises must be made.