4 ms·

> 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

> 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.

jacques_chester 13y ago
1. They're not orthogonal rules. 2. Some functions are queries that don't require an arguments. Eg. getVariable().
- jcampbell1 13y ago
  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.
  - jacques_chester 13y ago
    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.
dack 13y ago
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.
- raylu 13y ago
  And what is it doing with that calculation?
  - gfunk911 13y ago
    Returning it.
gizmo686 13y ago
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.
- retrogradeorbit 13y ago
  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.
  - gizmo686 13y ago
    >Just make the function take two arguments. And then use currying. Isn't that what I said?
jasonlotito 13y ago
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.
- gruseom 13y ago
  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.
- colomon 13y ago
  Isn't that a side effect?
  - ruficornis 13y ago
    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...)
    - colomon 13y ago
      That's not how I've usually seen the term side effect used in CS: http://en.wikipedia.org/wiki/Side_effect_(computer_science) 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.)
galaktor 13y ago
A method that acts as a "getter" by querying some sort of state wouldn't take arguments and shouldn't have side effects.

jacques_chester 13y ago

1. They're not orthogonal rules. 2. Some functions are queries that don't require an arguments. Eg. getVariable().

jcampbell1 13y ago
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.
- jacques_chester 13y ago
  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.

dack 13y ago

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.

raylu 13y ago
And what is it doing with that calculation?
- gfunk911 13y ago
  Returning it.

gizmo686 13y ago

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.

retrogradeorbit 13y ago
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.
- gizmo686 13y ago
  >Just make the function take two arguments. And then use currying. Isn't that what I said?

jasonlotito 13y ago

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.

gruseom 13y ago
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.
colomon 13y ago
Isn't that a side effect?
- ruficornis 13y ago
  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...)
  - colomon 13y ago
    That's not how I've usually seen the term side effect used in CS: http://en.wikipedia.org/wiki/Side_effect_(computer_science) 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.)

galaktor 13y ago

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