7 ms·

How do you handle Javascript ignoring wrong numbers of function arguments? Do you use a linter to catch this sort of thing? This part of Javascript sounds the

by Peaker 13y ago

How do you handle Javascript ignoring wrong numbers of function arguments? Do you use a linter to catch this sort of thing? This part of Javascript sounds the most absolutely insane to me: Silencing an error like that is catastrophic.

gkoberger 13y ago
It's just never been a problem for me, I guess? I know how it works in JS, so I either ignore it or use it to my advantage (the JS equivalent of overloading). You seem to come from a more strongly-typed background, but I've never once found the way JS handles it to be "catastrophic".
- Peaker 13y ago
  How do you ignore it? Ignoring it means accepting cryptic bugs that result from signature changes. You say "use to your advantage", but what's the advantage? You could have a "*args" like Python, and get the benefits without the (huge) drawback. The typing debate is mostly about how much effort we should exert to catch errors at compile time rather than run time. In JS, it is much worse: It defers error catching forever, and never even catches them at all! It converts them to silent bugs, instead :(
powatom 13y ago
Is this so much of a problem that we need to re-design JS to handle it? Why not just avoid making this mistake in the first place by reading the code? Not to sound dismissive - but if you're making these kinds of mistakes regularly enough to irritate you, it's not the language that's at fault. Javascript's squishiness is the thing I like the most about it. It's far from perfect, just like any other language out there - but it's fun.
- gumballhead 13y ago
  This. People complaining about what JavaScript lets you do just need to learn how to exploit its strengths while being aware of its dangers. It's like someone complaining that git let them make a mess after they merged master into their feature branch and then merge it back into master.
  - Peaker 13y ago
    No, it's much more like git ignoring wrong command syntax and just using undefined instead. git commit - m"Hi" && git push Let's push a commit with an undefined message, and ignore the m"Hi" argument. Error messages are annoying.
- Peaker 13y ago
  > Why not just avoid making this mistake in the first place by reading the code? We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior.
  - powatom 13y ago
    > We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Not at all, I'm simply suggesting that people take care to acknowledge and operate within the rules of the language. If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. JS allows you to do something which when ignored or fucked up, results in problems. This is not a JSism - this is just the way things work. Every language has 'features' like this. If you don't know what you're doing, then stop doing it. "A bad workman blames his tools" and all that jazz. > Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. So JS has a (potentially) higher maintenance cost. This doesn't mean that JS is badly designed - it's just a trade-off. Some people don't care, others do. Clearly to some people, it's an unacceptable cost - but all that means is that those people have a lower tolerance for that kind of thing than others. > Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior. This is just a case for good documentation and release notes. Don't merge in changes that you don't understand.
    - Peaker 13y ago
      > If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. Given that other people are working on the same code base and may have added calls to this function, this is not even possible. Also, dynamic languages all require you to fix calls to changed functions. But at least, when you test that code, it won't accidentally seem to work when it is broken. Also, humans cannot do a perfect job every time. We will all make mistakes, and our tools shouldn't give us hell over those mistakes for miniscule to no benefit at all as in this case. Out of thousands of changes to function signatures, do you think none would ever forget to fix a caller? > So JS has a (potentially) higher maintenance cost This doesn't sound potential at all. It sounds like you either lose a huge amount of reliability, or add a huge burden to development. > it's just a trade-off What do you gain here? You save an asterisk in the syntax when you want to overload? > This is just a case for good documentation and release notes. Don't merge in changes that you don't understand. In a collaborative environment, we merge work with each other every single day. Do you have documentation and release notes for every commit you publish? Do you go and check the commit's release notes every time you pull?
Wintamute 13y ago
Generally speaking, in the JS world at least, if you're passing more than a few parameters into a function you might have code complexity problems. If you need to pass in a bunch of data to a function you tend to do it in a single options object with some runtime checking to work out what to do with it. Any remaining problems should be caught with good test coverage. Being able to flexibly and clearly handle variable numbers of function arguments without getting entangled in an involved function overloading syntax and methodology is actually sometimes pretty nice. It's a feature not a problem. Haha :P
- forgottenpass 13y ago
  >>How do you handle Javascript ignoring wrong numbers of function arguments? >if you're passing more than a few parameters into a function I didn't know you had to have "more than a few parameters" before you could make a coding error related to the number of parameters you pass something.
arethuza 13y ago
I think the way libraries like jQuery use this behaviour to define their own undefined that is indeed undefined is rather neat, the whole of jQuery is wrapped in: (function(window, undefined) {...})(window);
callum85 13y ago
Silencing an error like that is catastrophic. Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this flexibility makes things easier and more expressive, in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences.
- anon1385 13y ago
  It's still a programmer error when they accidentally call a function with 2 arguments when they meant to call it with 3. The fact that the language can't inform them of the error doesn't change that.
  - marrs 13y ago
    So do some error checks. The first unit test I write for any function is that it handles arguments correctly.
    - prof_hobart 13y ago
      That's great if it's your function that's the problem. Less so if it's someone else's. And it's not only these kinds of errors that can cause silent failure. I've had it on missing brackets, on missing commas, on failure to include/require the right source file etc, etc. No error message, no warning, no log entry, no nothing. Just silence. And a blank output. Not overly helpful.
    - anon1385 13y ago
      But you do see why people are complaining, right? You are having to manually write thousands of tests to check something that is trivial for a compiler to check.
      - gnaritas 13y ago
potch 13y ago
In JS, sending the "wrong" number of arguments is frequently a feature. There's no concept of language-level function overloading, and it allows for the authorship of functions that take a variable or unbounded number of arguments (useful when coding in a functional paradigm).
- admnor 13y ago
  That "feature" would be better with an explicit language construct such as *args or params args[], though. As with so many complaints about JavaScript, it's the default behaviour that is a problem.
  - Peaker 13y ago
    I'd say it's worse than a default behavior, since there's no sane way to reverse the default. Are explicit arg list checks really an option, when you want to opt out of the default? I'd say that's not practical at all -- so it's really worse, as there's no practical opt out of this.
  - jakub_g 13y ago
    ES6 brings "rest parameter" [0]. function(param1, param2, ...rest) {} [0] http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html

by Peaker 13y ago

gkoberger 13y ago

It's just never been a problem for me, I guess? I know how it works in JS, so I either ignore it or use it to my advantage (the JS equivalent of overloading). You seem to come from a more strongly-typed background, but I've never once found the way JS handles it to be "catastrophic".

Peaker 13y ago
How do you ignore it? Ignoring it means accepting cryptic bugs that result from signature changes. You say "use to your advantage", but what's the advantage? You could have a "*args" like Python, and get the benefits without the (huge) drawback. The typing debate is mostly about how much effort we should exert to catch errors at compile time rather than run time. In JS, it is much worse: It defers error catching forever, and never even catches them at all! It converts them to silent bugs, instead :(

powatom 13y ago

Is this so much of a problem that we need to re-design JS to handle it? Why not just avoid making this mistake in the first place by reading the code? Not to sound dismissive - but if you're making these kinds of mistakes regularly enough to irritate you, it's not the language that's at fault. Javascript's squishiness is the thing I like the most about it. It's far from perfect, just like any other language out there - but it's fun.

gumballhead 13y ago
This. People complaining about what JavaScript lets you do just need to learn how to exploit its strengths while being aware of its dangers. It's like someone complaining that git let them make a mess after they merged master into their feature branch and then merge it back into master.
- Peaker 13y ago
  No, it's much more like git ignoring wrong command syntax and just using undefined instead. git commit - m"Hi" && git push Let's push a commit with an undefined message, and ignore the m"Hi" argument. Error messages are annoying.
Peaker 13y ago
> Why not just avoid making this mistake in the first place by reading the code? We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior.
- powatom 13y ago
  > We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Not at all, I'm simply suggesting that people take care to acknowledge and operate within the rules of the language. If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. JS allows you to do something which when ignored or fucked up, results in problems. This is not a JSism - this is just the way things work. Every language has 'features' like this. If you don't know what you're doing, then stop doing it. "A bad workman blames his tools" and all that jazz. > Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. So JS has a (potentially) higher maintenance cost. This doesn't mean that JS is badly designed - it's just a trade-off. Some people don't care, others do. Clearly to some people, it's an unacceptable cost - but all that means is that those people have a lower tolerance for that kind of thing than others. > Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior. This is just a case for good documentation and release notes. Don't merge in changes that you don't understand.
  - Peaker 13y ago
    > If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. Given that other people are working on the same code base and may have added calls to this function, this is not even possible. Also, dynamic languages all require you to fix calls to changed functions. But at least, when you test that code, it won't accidentally seem to work when it is broken. Also, humans cannot do a perfect job every time. We will all make mistakes, and our tools shouldn't give us hell over those mistakes for miniscule to no benefit at all as in this case. Out of thousands of changes to function signatures, do you think none would ever forget to fix a caller? > So JS has a (potentially) higher maintenance cost This doesn't sound potential at all. It sounds like you either lose a huge amount of reliability, or add a huge burden to development. > it's just a trade-off What do you gain here? You save an asterisk in the syntax when you want to overload? > This is just a case for good documentation and release notes. Don't merge in changes that you don't understand. In a collaborative environment, we merge work with each other every single day. Do you have documentation and release notes for every commit you publish? Do you go and check the commit's release notes every time you pull?

Wintamute 13y ago

Generally speaking, in the JS world at least, if you're passing more than a few parameters into a function you might have code complexity problems. If you need to pass in a bunch of data to a function you tend to do it in a single options object with some runtime checking to work out what to do with it. Any remaining problems should be caught with good test coverage. Being able to flexibly and clearly handle variable numbers of function arguments without getting entangled in an involved function overloading syntax and methodology is actually sometimes pretty nice. It's a feature not a problem. Haha :P

forgottenpass 13y ago
>>How do you handle Javascript ignoring wrong numbers of function arguments? >if you're passing more than a few parameters into a function I didn't know you had to have "more than a few parameters" before you could make a coding error related to the number of parameters you pass something.

arethuza 13y ago

I think the way libraries like jQuery use this behaviour to define their own undefined that is indeed undefined is rather neat, the whole of jQuery is wrapped in: (function(window, undefined) {...})(window);

callum85 13y ago

Silencing an error like that is catastrophic. Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this flexibility makes things easier and more expressive, in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences.

anon1385 13y ago
It's still a programmer error when they accidentally call a function with 2 arguments when they meant to call it with 3. The fact that the language can't inform them of the error doesn't change that.
- marrs 13y ago
  So do some error checks. The first unit test I write for any function is that it handles arguments correctly.
  - prof_hobart 13y ago
    That's great if it's your function that's the problem. Less so if it's someone else's. And it's not only these kinds of errors that can cause silent failure. I've had it on missing brackets, on missing commas, on failure to include/require the right source file etc, etc. No error message, no warning, no log entry, no nothing. Just silence. And a blank output. Not overly helpful.
  - anon1385 13y ago
    But you do see why people are complaining, right? You are having to manually write thousands of tests to check something that is trivial for a compiler to check.
    - gnaritas 13y ago

potch 13y ago

In JS, sending the "wrong" number of arguments is frequently a feature. There's no concept of language-level function overloading, and it allows for the authorship of functions that take a variable or unbounded number of arguments (useful when coding in a functional paradigm).

admnor 13y ago
That "feature" would be better with an explicit language construct such as *args or params args[], though. As with so many complaints about JavaScript, it's the default behaviour that is a problem.
- Peaker 13y ago
  I'd say it's worse than a default behavior, since there's no sane way to reverse the default. Are explicit arg list checks really an option, when you want to opt out of the default? I'd say that's not practical at all -- so it's really worse, as there's no practical opt out of this.
- jakub_g 13y ago
  ES6 brings "rest parameter" [0]. function(param1, param2, ...rest) {} [0] http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html http://ariya.ofilabs.com/2013/03/es6-and-rest-parameter.html