RE: [jslint] Re: unused variable in parameters
Expand Messages
- Wrap each call:
/*jslint unparam:true */
myResult = myFunc(a,b,c);
/*jslint unparam:false */
After about your third of these, "tolerate unused" or ignoring the JSLint
error starts looking pretty tasty. You could wrap the library in an
"approved" api, but that layer of indirection insures developer training and
code maintenance goes up; it doesn't insure that code is less error prone.
It'd be nice if "tolerate unused" could be separated into "tolerate unused
function params" and "tolerate unused calls", the latter absolving the
library you have no control over, the former validates you behave yourself
because you're not linting their code. Or perhaps in a similar way to
declaring globals, we could declare "tolerate" options per namespace. Alas,
the argument against this complexity will instruct me to "fix" the target
library in spite of existing users or release schedules because no bad
JavaScript should be tolerated. If only the business world were that
academic.
Rob
-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Satyam
Sent: Monday, December 19, 2011 10:48 AM
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] Re: unused variable in parameters
On 12/19/2011 06:18 PM, douglascrockford wrote:
>
> --- In jslint_com@yahoogroups.com
> <mailto:jslint_com%40yahoogroups.com>
> <mailto:jslint_com%40yahoogroups.com>, Satyam <satyam@...> wrote:
>
> > An unused argument in an argument list should not be reported as an
> > 'unused variable' if there are more arguments in the argument list.
> > It is not unused, it is a placeholder.
>
> This is sometimes an indication of a coding error or a design error.
> If you are doing this intentionally, which is probably a bad idea,
> then use the Tolerate unused parameters option.
>
>
It often happens when writing functions that register as callbacks.
Libraries try to provide enough information for whatever the listener might
need. They might pass all the values as properties in an object in a single
argument but here, this particular listener provides just three arguments,
it is really not a bad design decision. If there had been 10 arguments, that
would be an awful design, 3 arguments is on the edge. I have no control on
the library, I just listen to it.
So, it is not a design or coding error and I don't care to tolerate unused
parameters elsewhere.
Anyway, as I said, it is not a big issue.
[Non-text portions of this message have been removed]
- I like this error.
It reminds me every time that I have a method that needs to be reviewed.
[Non-text portions of this message have been removed]
Your message has been successfully submitted and would be delivered to recipients shortly.