Difference between findPos("divThis") and findPos(divThis)

[Thomas 'PointedEars' Lahn]

Considering only the given code by Cal, it creates two implied global
variables (w and h),

No. What happens is what I described, which is compliant with ECMAScript
Edition 3 Final, sections 11.13.1 and 8.6.2, and Editions 5 and 5.1,
sections 11.13.1 and 8.7.2, respectively.

according to ECMA-262 3rd, section 12.2:

The current edition of ECMAScript is 5.1, June 2011 CE; not Edition 3
(Final), December 1999/March 2000 CE.

"If the variable statement occurs inside a FunctionDeclaration, the
variables are defined with function-local scope in that function, as
described in s10.1.3. Otherwise, they are defined with *global scope*
(that is, they are created as members of the global object, as described
in 10.1.3) [...]"

That section's second sentence refers to *variable statements* outside of a
FunctionDeclaration, as made obvious by its first sentence.

As written above, the correct terminology is indeed "variable defined in
the function-local scope".

No, a "variable defined *with* function-local scope" is something else than
"a variable defined *in* the function-local scope" (which you also did not
say before). The proper term for such a variable is _local_ variable, _not_
a "private" variable (whereas you said the latter before).

ACK, except for the *only*.

Please name a counter-example using ECMAScript-conforming code where a
`private'-like property visibility is achieved explicitly.

It's not wrong, it's a different approach instead.

No, it is wrong to say "must not use". "Must not" in English means "is not
allowed to". It is certainly allowed to use that syntactical construct, as
it constitutes nothing more than consecutive statements.

ECMAScript permits using either a single var or many var statements as one
wishes.

That is not what you said before.

I prefer the single var pattern.

That is also not what you said before.

And I don't care about Eclipse - I'm talking about JavaScript not JAVA.

Will you please at least *try* get yourself educated before you post?
Eclipse JSDT is the Eclipse _JavaScript_ Development Tools plugin.

Personally, I prefer Python / Django but it doesn't matter to this
discussion anyway.

Yes, it matters how a commonly used JavaScript IDE can deal with either of
those syntactical constructs.


PointedEars

 

[Eric Bednarz]

The comma operator does not help with this.

The comma operator does not help with this.

The comma …

RTFM. Anyhow, the earlier everybody exclusively uses the single var
pattern, the earlier the shitty Eclipse JSDT will get fixed.

 

[J.R.]

In your humble opinion (which may not even be your opinion but that of the
author of some botched book you read instead, and now you think you know the
language and its "best practices").

I still have a long and winding road to go until I get a thorough
comprehension about JavaScript. But what about you?

You are confusing two concepts here.

No, I am not.

The comma operator does not help with this.


The comma operator does not help with this.

Read again and notice that I was writing about adopting the Single var
Pattern, instead of writing many var statements. It's not about using
commas.

The comma …


Sometimes. Because for readable code, you will have to indent the second,
third aso. line. In particular, with the style you used above, you do not
save or add *any* byte. If this is not obvious to you, look more carefully:

var.el.=....,.........
....h =....,..........
....w.=....,..........
....i,.j,.len,....,.z;

vs.

var.el.=....;.........
var.h.=....;..........
var.w.=....;..........
var.i,.j,.len,....,.z;

Yes, it is obvious to anyone. But what if we minify our code
<http://en.wikipedia.org/wiki/Minification_(programming)>, leaving out
unnecessary spaces? Code Minification is one of the best practices in
Javascript.

At any rate, the potential savings are so very small compared to what
trimming comments, minimization and gzipping can achieve that this is not a
convincing argument. Taking my current local object.js as an example:

[snip]

which saves *nothing* with \n =<LF> but *adds* one byte with \n =<CR><LF>
as it means removing a space [−1] and adding a newline [+1|+2] on the first
line, adding two spaces [+2] on the second line, and removing "var" (3 bytes
[−3]) and adding a space [+1] on the third line).

[snip]

which means removing one space [−1] and adding one newline [+1|+2] on the
first line, adding one<HT> [+1] on the second line and saving 3 bytes [−3]
on the second line (a total of only 1 or two 2 saved bytes). (However, tab
indentation may require additional adjustments at the reader's, and is
therefore also not recommended for posting to Usenet.)

Obviously, you are not considering a file with hundreds, perhaps
thousands of lines. Code minification is a good practice, supported by
renowned JS developers and browser-vendors no matter how hard you try to
deny it just because you want do disqualify my statement. I really think
that you do not believe in your own words.

Your logic is flawed:<http://en.wikipedia.org/wiki/Ipse_dixit>

When there is nothing left to say, you really enjoy finishing a
discussion off with this sort of Mr. Spock citation (Your logic is
flawed). Very characteristic.

 

[Richard Cornford]

"must not" was exaggerated on purpose, because using many var
statements is an antipattern in JavaScript.

<URL: http://en.wikipedia.org/wiki/Anti-pattern > describes an
antipattern as:-

"In software engineering, an anti-pattern (or antipattern) is a
pattern that may be commonly used but is ineffective and/or
counterproductive in practice."

- which seems to require ineffective and/or counterproductive, both of
which could be demonstrated if true. However, ineffective is obviously
not relevant to variable declarations, as they are effective, with
near zero difference in behaviour between single variable declaration
statements and multiple variable declaration statements. So it is
counterproductive that seems pertinent, and given that this thread has
already demonstrated that continuing a statement across multiple lines
with each line except the last terminated with a comma is far from an
error resistant practice, the 'productivity' balance seems to already
have tipped away from this practice..

Personally I think that the comma is too visually indistinct and also
too visually similar to a semicolon to be a good candidate for source
code line termination. That is, it is not easy to see that you have
done the right thing while writing it, and it is also not easy for a
later reader to see what the code is attempting to do (and doing it
correctly or not). I tend to see opaque source code text as
counterproductive in itself.

That would be ridiculously dogmatic of them.

And some people put variable declarations on a single line until that
line starts to get too long (for some arbitrary definition of too long
(or a formal coding standard if applicable) and the start a new
variable declaration statement on the next line.

The advantages of using the Single var Pattern at the top of your
functions are:
- there's a single place to look for all the local variables needed
by the function;

This is not an advantage over multiple consecutive variable
declaration statements at the top of that same function. And since a
single statement could become very long or extended over multiple
lines that is likely to become difficult to read and understand,
negating some of the advantage of only looking in a single place.

- prevention of logical errors when a variable is used before it’s
defined;

This is not an advantage over multiple consecutive variable
declaration statements at the top of that same function. And what do
"logical errors" consist of in this context? If variables are declared
they are declared as an execution context is entered.

In my experience when people have made a case for declaring variables
at the top of a function body it is on order that the structure/order
of the source code reflect the way in which the javascript engine is
going to behave (handling the declarations before any actual code
execution). It would seem an unjustified misapplication of this
justification to insist that those variable declarations be confined
to a single statement (especially since that same recommendation wants
the inner function declarations to appear at the top of the function
body as well, and they cannot be combined into a single statement).

- Helps you remember to declare variables and therefore minimize
globals;

This is not an advantage over multiple consecutive variable
declaration statements at the top of that same function.

- only one var statement means less code to type and a reduction
in the file size.

So it would be (at best) the opportunity to save half a dozen bytes
that is the only factor left that could justify the "antipattern"
assertion, on the grounds of the alternatives being
counterproductive. I won't be buying that argument as this would be
neutralised by zipping the resource to be sent to the client, while
the potential added obscurity in the source code looks too negative to
me.

There are patterns in any programming language usually adopted
by programmers as "best coding practices". And it happens to
other fields of study too. See
<http://en.wikipedia.org/wiki/Best_Coding_Practices>

Maybe, but a high proportion of "best practices" that have been
proposed for javascript have been pretty much BS. Misunderstandings/
miscomprehensions abound, but the people looking for rules that will
supposedly help them cannot easily tell. I always recommend that no
"best practice" should be taken seriously unless it is presented
alongside a reasoned justification, and that that justification stands
up to critical scrutiny. For anything that really is a "best practice"
that should be an achievable requirement.

And having seen your reasoning for only using a single variable
declaration statement per function body, it didn’t stand up.

If you get a bunch of authors (books, blogs, etc.) that state the
same "best practices" in any programming language, then you can
bet who is wrong or right...

Not with javascript. Nonsense propagates like wildfire in this field.
Hence the need to look at the actual reasoning and not be impressed by
any argument from numbers.

No, it doesn't, although I know you're a very experienced and
smart programmer.

Do you really know that? (and should it matter anyway as in isolation
that would only make for an argument from authority?)

However, if you published some evidence such
as performance tests, etc.,

Yes, test cases are really good at demonstrating a point. Indeed if
properly designed are much more convincing than reasoned argument. So
can the alternatives to using a single variable declaration statement
at the start of a function body be demonstrated to be
counterproductive with some test case?

then you could state that some practice
should be either considered a good one or avoided altogether.

Performance isn't everything. In practice most javascript performs
just fine (and ironically better and better as CPUs and javascript
engines get faster). It will be useful to know what factors impact
performance, so as to be able to achieve it when necessary or avoid
squandering it, but it has long been the case that the biggest expense
in software production is accounted for by code maintenance, making
source code clarity (readability, understandably and self-documenting-
ness) a completely valid subject for "best practices", and putting the
variable declarations at the top of a function body was originally
primarily about code clarity.

Richard.

 

[Thomas 'PointedEars' Lahn]

I still have a long and winding road to go until I get a thorough
comprehension about JavaScript. But what about you?


No, I am not.

Yes, you are. One, declaring variables either on top of a function body or
anywhere. Two, using either consecutive `var' statements or one `var'
statement with a list.

Read again and notice that I was writing about adopting the Single var
Pattern, instead of writing many var statements. It's not about using
commas.

Apparently you don't even know what you write.

Yes, it is obvious to anyone.

Not to you, obviously, as you were claiming that your approach would save
space. It doesn't.

But what if we minify our code>
<http://en.wikipedia.org/wiki/Minification_(programming)>, leaving out
unnecessary spaces?

A good minifier should indeed be capable to make one variable statement out
of consecutive ones. Minification becomes relevant when serving resources,
not when storing them.

Code Minification is one of the best practices in Javascript.

Says who? The same person who says you must not use consecutive variable
statements? I see.

At any rate, the potential savings are so very small compared to what
trimming comments, minimization and gzipping can achieve that this is not
a convincing argument. Taking my current local object.js as an example:

[snip]

which saves *nothing* with \n =<LF> but *adds* one byte with \n
=<CR><LF> as it means removing a space [−1] and adding a newline [+1|+2]
on the first line, adding two spaces [+2] on the second line, and
removing "var" (3 bytes [−3]) and adding a space [+1] on the third line).

[snip]

which means removing one space [−1] and adding one newline [+1|+2] on the
first line, adding one<HT> [+1] on the second line and saving 3 bytes
[−3]
on the second line (a total of only 1 or two 2 saved bytes). (However,
tab indentation may require additional adjustments at the reader's, and
is therefore also not recommended for posting to Usenet.)

Obviously, you are not considering a file with hundreds, perhaps
thousands of lines.

Obviously you can't read.

Perhaps I should take David Mark's approach instead, and simply send you to
bed from time to time. Currently at least, your higher brain functions do
not appear to be very active.


PointedEars

 

[J.R.]

Says who? The same person who says you must not use consecutive variable
statements? I see.

I would not say one person, but *many* experienced and renowned JS
developers and all major browser-vendors. Google and find by yourself.

At any rate, the potential savings are so very small compared to what
trimming comments, minimization and gzipping can achieve that this is not
a convincing argument. Taking my current local object.js as an example:

[snip]

which saves *nothing* with \n =<LF> but *adds* one byte with \n
=<CR><LF> as it means removing a space [−1] and adding a newline [+1|+2]
on the first line, adding two spaces [+2] on the second line, and
removing "var" (3 bytes [−3]) and adding a space [+1] on the third line).

[snip]

which means removing one space [−1] and adding one newline [+1|+2] on the
first line, adding one<HT> [+1] on the second line and saving 3 bytes
[−3]
on the second line (a total of only 1 or two 2 saved bytes). (However,
tab indentation may require additional adjustments at the reader's, and
is therefore also not recommended for posting to Usenet.)

Obviously, you are not considering a file with hundreds, perhaps
thousands of lines.

Obviously you can't read.

Perhaps I should take David Mark's approach instead, and simply send you to
bed from time to time. Currently at least, your higher brain functions do
not appear to be very active.

LOL. Very entertaining.

 

[Thomas 'PointedEars' Lahn]

I would not say one person, but *many* experienced and renowned JS
developers and all major browser-vendors. Google and find by yourself.

There we have the "ipse dixit" fallacy again.


PointedEars

 

[J.R.]

<URL: http://en.wikipedia.org/wiki/Anti-pattern> describes an
antipattern as:-

"In software engineering, an anti-pattern (or antipattern) is a
pattern that may be commonly used but is ineffective and/or
counterproductive in practice."

- which seems to require ineffective and/or counterproductive, both of
which could be demonstrated if true. However, ineffective is obviously
not relevant to variable declarations, as they are effective, with
near zero difference in behaviour between single variable declaration
statements and multiple variable declaration statements. So it is
counterproductive that seems pertinent, and given that this thread has
already demonstrated that continuing a statement across multiple lines
with each line except the last terminated with a comma is far from an
error resistant practice, the 'productivity' balance seems to already
have tipped away from this practice..

Personally I think that the comma is too visually indistinct and also
too visually similar to a semicolon to be a good candidate for source
code line termination. That is, it is not easy to see that you have
done the right thing while writing it, and it is also not easy for a
later reader to see what the code is attempting to do (and doing it
correctly or not). I tend to see opaque source code text as
counterproductive in itself.


That would be ridiculously dogmatic of them.


And some people put variable declarations on a single line until that
line starts to get too long (for some arbitrary definition of too long
(or a formal coding standard if applicable) and the start a new
variable declaration statement on the next line.


This is not an advantage over multiple consecutive variable
declaration statements at the top of that same function. And since a
single statement could become very long or extended over multiple
lines that is likely to become difficult to read and understand,
negating some of the advantage of only looking in a single place.


This is not an advantage over multiple consecutive variable
declaration statements at the top of that same function. And what do
"logical errors" consist of in this context? If variables are declared
they are declared as an execution context is entered.

In my experience when people have made a case for declaring variables
at the top of a function body it is on order that the structure/order
of the source code reflect the way in which the javascript engine is
going to behave (handling the declarations before any actual code
execution). It would seem an unjustified misapplication of this
justification to insist that those variable declarations be confined
to a single statement (especially since that same recommendation wants
the inner function declarations to appear at the top of the function
body as well, and they cannot be combined into a single statement).


This is not an advantage over multiple consecutive variable
declaration statements at the top of that same function.


So it would be (at best) the opportunity to save half a dozen bytes
that is the only factor left that could justify the "antipattern"
assertion, on the grounds of the alternatives being
counterproductive. I won't be buying that argument as this would be
neutralised by zipping the resource to be sent to the client, while
the potential added obscurity in the source code looks too negative to
me.


Maybe, but a high proportion of "best practices" that have been
proposed for javascript have been pretty much BS. Misunderstandings/
miscomprehensions abound, but the people looking for rules that will
supposedly help them cannot easily tell. I always recommend that no
"best practice" should be taken seriously unless it is presented
alongside a reasoned justification, and that that justification stands
up to critical scrutiny. For anything that really is a "best practice"
that should be an achievable requirement.

And having seen your reasoning for only using a single variable
declaration statement per function body, it didn’t stand up.


Not with javascript. Nonsense propagates like wildfire in this field.
Hence the need to look at the actual reasoning and not be impressed by
any argument from numbers.


Do you really know that?

Yes, I do.

(and should it matter anyway as in isolation
that would only make for an argument from authority?)

No, it shouldn't matter because of the "fallacy of authority"

Yes, test cases are really good at demonstrating a point. Indeed if
properly designed are much more convincing than reasoned argument. So
can the alternatives to using a single variable declaration statement
at the start of a function body be demonstrated to be
counterproductive with some test case?


Performance isn't everything. In practice most javascript performs
just fine (and ironically better and better as CPUs and javascript
engines get faster). It will be useful to know what factors impact
performance, so as to be able to achieve it when necessary or avoid
squandering it, but it has long been the case that the biggest expense
in software production is accounted for by code maintenance, making
source code clarity (readability, understandably and self-documenting-
ness) a completely valid subject for "best practices", and putting the
variable declarations at the top of a function body was originally
primarily about code clarity.

Dear Richard,
Besides being a gentleman while writing your brilliant ideas down, you
were impeccable in your above comments! I must agree with you. Thank you
very much indeed.

PS. It's a pity that Thomas Lahn is not well educated and polite as you
and many others in this newsgroup. Although he really knows a lot about
JavaScript, his responses are usually unpleasant and aggressive. Also he
has a stupefying habit of changing his points of view just to discredit
someone.

 

[Denis McMahon]

You are right, I should have not used the "must not" as it expresses
prohibition in English, and a code pattern is not necessarily one of the
"best coding practices", although, in many cases, they seem to walk hand
in hand. And sticking to a strict coding style is usually considered one
of the best practices in many programming languages.

Examples of "best practices" in JS:
<http://dev.opera.com/articles/view/javascript-best-practices/>

Yep, read that.

The above link is propped up by the Mozilla Developer Network
<https://developer.mozilla.org/en-US/learn/javascript>, and there are
other pages at MDN concerning to best practices in other aspects of
development (extensions, security, ect.).

Noted that.

Can't see the bit about combining all the variable declarations into a
single var statement though.

Psst, jslint doesn't seem to want that either, it's quite happy as long
as (a) all variables are defined (b) at the start of the function.

Minimisation is good, but the following:

var a = "df";
var b = 17;
var c = [{s:'monkey',x:'male',a:3},{s:'elephant',x:'female',a:7},
{s:'mule',x:'neuter',a:1}];
var c1 = ["alpha","beta","gamma"];
var c2 = {o:'peter',f:'grass',z:'oregon',d:[{x:'male',q:3},
{x:'female',q:4}]};
var d = "mary had a little lamb";
var e = f = g = 0;

is going to be much easier to maintain than a single minimised statement:

var a="df",b=17,c=[{s:'monkey',x:'male',a:3},
{s:'elephant',x:'female',a:7},{s:'mule',x:'neuter',a:1}],c1=
["alpha","beta","gamma"],c2={o:'peter',f:'grass',z:'oregon',d:
[{x:'male',q:3},{x:'female',q:4}]},d="mary had a little lamb",e=f=g=0;

even if you do use more sensible variable and property names than the
ones I've selected.

Rgds

Denis McMahon

 

[Evertjan.]

Denis McMahon wrote on 14 nov 2011 in comp.lang.javascript:

var e = f = g = 0;

This is not the same as:

var f;
var g;
var e = f = g = 0;

 

[Denis McMahon]

Do you really know that? (and should it matter anyway as in isolation
that would only make for an argument from authority?)

Personally I think of myself as reasonably competent, but I also know
that after some 34 years of computer programming I'm still learning.

Rgds

Denis McMahon

 

[J.R.]

There we have the "ipse dixit" fallacy again.

No, it is more like "vox populi, vox Dei"...

 

[Thomas 'PointedEars' Lahn]

No, it is more like "vox populi, vox Dei"...

IOW: Faith, not science. I rest my case.


PointedEars

 

[Scott Sauyet]

Minimisation is good, but the following:

var a = "df";
var b = 17;
var c = [{s:'monkey',x:'male',a:3},{s:'elephant',x:'female',a:7}, {s:'mule',x:'neuter',a:1}];
[ ... ]

is going to be much easier to maintain than a single minimised statement:

var a="df",b=17,c=[{s:'monkey',x:'male',a:3}, {s:'elephant',x:'female',a:7},{s:'mule',x:'neuter',a:1}],// [ ... ]

even if you do use more sensible variable and property names than the
ones I've selected.

Another contender is this:

var a = "df",
b = 17;
c = [{s:'monkey',x:'male',a:3},{s:'elephant',x:'female',a:7},
{s:'mule',x:'neuter',a:1}],
/* ... */;

Or, as Thomas suggests, this:

var
a = "df",
b = 17,
c = [{s:'monkey',x:'male',a:3},{s:'elephant',x:'female',a:7},
{s:'mule',x:'neuter',a:1}],
/* ... */;


These both compress well and are still readable. Richard's argument
against the comma are reasonable, and in choosing whether you want to
do this, you need to weigh the concerns he raises about commas making
the source more opaque against the ability to better minify the source
code.

-- Scott

 

[Gene Wirchenko]

[snip]

Rubbish.

You can use as many var statements as you like. Nothing in the standards
or the implementation prevents this, so "must not" is incorrect.

"must not" was exaggerated on purpose, because using many var statements
is an antipattern in JavaScript.

Exaggerating to make a point is an anti-pattern of its own. It
means that anyone reading what you write can not simply take it at
face value, but now has to figure out whether the meaning to use is
the literal one or a weaker form of it.

[snip]

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

On Nov 14, 5:14 am, J.R. wrote:
[snip]

The advantages of using the Single var Pattern at the top of your
functions are: [snip]
- Helps you remember to declare variables and therefore minimize
globals;

This is not an advantage over multiple consecutive variable
declaration statements at the top of that same function.

In fact, it might be a disadvantage! Consider:
var a="somthing",
b="another"
c="YA"
which is correct but misleading code. c is not declared here. What
was intended was:
var a="somthing",
b="another",
c="YA"
(added a comma to the second line)

So it would be (at best) the opportunity to save half a dozen bytes
that is the only factor left that could justify the "antipattern"
assertion, on the grounds of the alternatives being
counterproductive. I won't be buying that argument as this would be
neutralised by zipping the resource to be sent to the client, while
the potential added obscurity in the source code looks too negative to
me.

I would rather type var a few more times and feel safer about my
code. See my example above. Sir Hoare said it well:

"I was eventually persuaded of the need to design programming
notations so as to maximize the number of errors which cannot be made,
or if made, can be reliably detected at compile time. Perhaps this
would make the text of programs longer. Never mind! Wouldn't you be
delighted if your Fairy Godmother offered to wave her wand over your
program to remove all its errors and only made the condition that you
should write out and key in your whole program three times!"

[snip]

Maybe, but a high proportion of "best practices" that have been
proposed for javascript have been pretty much BS. Misunderstandings/
miscomprehensions abound, but the people looking for rules that will
supposedly help them cannot easily tell. I always recommend that no
"best practice" should be taken seriously unless it is presented
alongside a reasoned justification, and that that justification stands
up to critical scrutiny. For anything that really is a "best practice"
that should be an achievable requirement.

Quite.

[snip]

Sincerely,

Gene Wirchenko

 

[Denis McMahon]

Denis McMahon wrote on 14 nov 2011 in comp.lang.javascript:


This is not the same as:

var f;
var g;
var e = f = g = 0;

Yes, you're right, my example didn't actually define f and g, only e. You
seem to be the only person who spotted it.

The "correct"[1] form is of course:

var e,f,g=e=f=0;

[1] in this context, "correct" means whatever I want it to mean!

Rgds

Denis McMahon

 

[Scott Sauyet]

Another contender is this:

var a = "df",
    b = 17;

            ^ oops!

    c = [{s:'monkey',x:'male',a:3},{s:'elephant',x:'female',a:7},

... .  Richard's argument against the comma are reasonable, ...

;-)

Perhaps I should have said "are eminently reasonable"."

-- Scott

 

[Frobernik]

Denis McMahon wrote:
Minimisation is good, but the following:

var a = "df";
var b = 17;

Another contender is this:

var a = "df",
b = 17;

^ oops!

c = [{s:'monkey',x:'male',a:3},{s:'elephant',x:'female',a:7},

... . Richard's argument against the comma are reasonable, ...

;-)

Perhaps I should have said "are eminently reasonable"."

-- Scott

You could squeeze more out of the available space and avoid the use of a
var completely

Using the original example

function findPos(obj) {
var w = obj.offsetWidth;
var h = obj.offsetHeight;
}
findPos(divThis)

becomes :-

function findPos(obj, w, h) {
w = obj.offsetWidth;
h = obj.offsetHeight;
}
findPos(divThis)

another style/variant could be

function findPos(obj, name, colour, b, c) {
name = obj.name;
colour = obj.colour;
b = 17;
c = [{s:'monkey', x:'male', a:3}, {s:'elephant',x:'female',a:7}];
}
findPos({name:'df', colour:'green'})

Frobernik

 

[Thomas 'PointedEars' Lahn]

You could squeeze more out of the available space and avoid the use of a
var completely

Using the original example

function findPos(obj) {
var w = obj.offsetWidth;
var h = obj.offsetHeight;
}
findPos(divThis)

becomes :-

function findPos(obj, w, h) {
w = obj.offsetWidth;
h = obj.offsetHeight;
}
findPos(divThis)

another style/variant could be

function findPos(obj, name, colour, b, c) {
name = obj.name;
colour = obj.colour;
b = 17;
c = [{s:'monkey', x:'male', a:3}, {s:'elephant',x:'female',a:7}];
}
findPos({name:'df', colour:'green'})

(Jorge, is it you?)

We have been over this.

Declaring arguments instead of local variables may be great for code golfing
(140 characters maximum), but it is a Really Bad Idea for all other code.
To begin with, by looking at the code you cannot tell whether you are
modifying an argument or not. Editors and linters which can differentiate
between arguments and local variables could not tell as well.


PointedEars
--

If you get a bunch of authors […] that state the same "best practices"
in any programming language, then you can bet who is wrong or right...

Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14