Hacker News Reader

Comment by jcampbell1 | Hacker News Reader

> Zero or one argument is easiest to understand and maintain.

> Have No Side Effects

Can someone explain how you use zero argument functions that doesn't have side effects? I am trying to wrap my head around these two statements.

View on HN

Having no side effects doesn't mean it can't do something. Only that it shouldn't do anything unexpected.

    storeItem.makeAvailable();

That should only make the store item available. It shouldn't re-enable a sale that was on the storeItem when it was made unavailable.

That's a zero-argument method but not a zero-argument function. That is, if you view makeAvailable as a function, storeItem is an implicit argument to it. In fact, storeItem is probably an object with several fields, so there are arguably several implicit arguments. To my eye, the name "makeAvailable" suggests a side-effect too.

In any case, it's fine for two rules such as "avoid side effects" and "prefer zero- or single-argument functions" to be in tension with one another. I don't buy that zero-or-one idea, though. A function should have as many arguments as it makes sense for it to have.

Isn't that a side effect?

That is more of an effect, not a side effect, no? Something still happens, but nothing very unexcpected. If a doctor gives you medicine for an ailment, you don't want it to have many side effects, but it intended effect is still desired (theoretically). Prehaps it should effect only what it needs to in order to give you or the next step it's output, not changing some finite machine state (unless...)

That's not how I've usually seen the term side effect used in CS: http://en.wikipedia.org/wiki/Side_effect_(computer_science)

In jasonlotito's example, he's definitely modifying state.

(Mind you, I don't think side effects should be banned outright or anything like that. But minimizing them is frequently a nice idea.)

Sorry, I was wrong. I did not read the comment closely nor was I familiar with the CS definition. Thank you for the information.

Yeah, pretty much. I generally agree with this definition: http://en.wikipedia.org/wiki/Side_effect_(computer_science)

I think instead of "side effect" the author should have used the more traditional term of cohesion:

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

You could have a method on a class that uses it's own fields to do some calculation. So, although it does have access to the fields on the class, it takes no arguments and has no side effects.

You could certainly argue that a class's fields are a form of input arguments to a method, and I would agree - which is why another good rule of thumb is to not have too many of those either!

Obviously, it's a balance, so none of the rules can be taken without context to the situation - they are all just smells that you should "back away from" if you're finding yourself breaking any given rule too much.

And what is it doing with that calculation?

Returning it.

I think it is all suggestions, not hard rules. Also, given that the quote allows you to use up to 1 argument, it is actually trivial to do (assuming you are fine with the no side effects part). The trick is that instead of taking 2 parameters, you take 1 parameter, than generate and return a function that takes 1 parameter. Probably not what the author has in mind.

Anyway, in the context of the rest of the post, it looks like object oriented programming is being discussed, in which case I think the implicit 'self' does not count as a parameter.

Or just make the function take two arguments. And then use currying (if your language supports it). A lot of this depends on language.

I definitely agree with you saying its suggestions, not hard rules. Unfortunately the author of the page keeps saying 'always' as if it's hard and fast rules.

Understand why and when first, then use where appropriate.

>Just make the function take two arguments. And then use currying.

Isn't that what I said?

1. They're not orthogonal rules.

2. Some functions are queries that don't require an arguments. Eg. getVariable().

I just find that minimizing parameters makes a mess with tons of side effects. When I see nothing but 0 and 1 parameter functions, the code is typically doing the logical equivalent of refactoring `add(a,b);` into `push(a);push(b);add();` which makes a mess when there is more than the trivial case.

jQuery.ajax is a 33 parameter function. No one complains, and it is nice that it doesn't have side effects.

Sure. Usually when you find a strict rule, it's a rule to be considered ceteris paribus -- when all other things are fixed in place. So while thinking about parameters, I think about minimising them and ignore other considerations. When thinking about side-effects, I think about minimising them and ignore other considerations.

It's when the rules conflict that mere rule-following ends and professional judgement begins.

Basically, as noted legal scholar Captain Barbossa observed, they're less like laws and more like guidelines.

A method that acts as a "getter" by querying some sort of state wouldn't take arguments and shouldn't have side effects.

Reply on news.ycombinator.com