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

[Frobernik]

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?)

No its not

We have been over this.

We have?

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.

An editor or linters not going to know more about my code than me

 

[Thomas 'PointedEars' Lahn]

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'})

We have been over this.

We have?

Yes. We, the previous subscribers of this newsgroup, have. You should read
a fair amount of past discussions before you post to a newsgroup:

An editor or linters not going to know more about my code than me

Whether that is true depends on what you *actually* know about your code.

I know at least one ECMAScript-supporting editor, which includes a linter,
that can differentiate between function arguments and local variables:
Eclipse JavaScript Developer Tools (JSDT).

It is rather obvious that this is possible for a machine because each
/FunctionDeclaration/ or /FunctionExpression/ has an argument list, and
identifiers need to be *declared* variable names in order to be *variable*
names. So the following heuristics can be applied to a standalone
/IdentifierName/ within a function body:

N¹ A V I B Meaning
-------------------------------------------------------------------------
− − − − + Probable ReferenceError (all modes)
− − − + + Possible "Implied global", i. e. property of an object in
the function scope's scope chain created; possible
ReferenceError (strict mode)
− − + − − Local variable, unused
− − + − + Local variable, used
− − + + + Local variable (initialized), used
– + − − – Function argument, unused
– + − − + Function argument, used
− + − + + Function argument (used), possible default value init.
− + + − − Local variable (unused), hiding a function argument
− + + − + Local variable (used, uninitialized), hiding a function
argument
− + + + + Local variable (used), hiding a function argument
+ − − − − Non-local property or variable
+ − − − + Property in the function scope's scope chain (perhaps
uninitialized), used
+ − − + + Property in the function scope's scope chain, used
+ − + − − Local variable (unused), hiding a property in the
function scope's scope chain
+ − + − + Local variable (used, uninitialized), perhaps hiding a
property in the function scope's scope chain
+ − + + + Local variable (used), hiding a property in the
function scope's scope chain
+ + − − – Function argument (unused), perhaps hiding a property in the
function scope's scope chain
+ + − − + Function argument (used), perhaps hiding a property in the
function scope's scope chain
+ + − + + Function argument (used, perhaps assigned to), perhaps hiding
a property in the function scope's scope chain
+ + + − − Local variable (unused), hiding a function argument,
which hides a property in the function scope's scope chain
+ + + − + Local variable (used), hiding a function argument,
which hides a property in the function scope's scope chain
+ + + + + Local variable (used, initialized), hiding a function
argument, which hides a property in the function scope's
scope chain
_____
¹) N: Non-local occurence
A: Occurence in function's argument list
V: VariableDeclaration in function body
I: Initialization/assignment in function body
B: Occurence in function body
+: Applies
−: Does not apply

In an implementation of similar heuristics, Eclipse JSDT allows function
arguments and variables to be displayed differently. For example, I have
set it up so that it would display argument declarations and references in
bluish italic characters; the identifier in variable declarations in regular
style, but underlined; and local variable references in normal-colored
italic characters. If I were to use your approach, I could not tell at a
glance if an identifier was an argument or a local variable name. I could
be ending up assigning to arguments, inadvertently altering the program flow
after that assignment. If someone would call my function, and I would
forget to assign to the argument but used it later, they could,
intentionally or accidentally, alter the inner workings of my function.

AISB, a Really Bad Idea for a number of reasons, another one being that in
an API you only expose to the world what needs to be exposed to it.


PointedEars

 

[Thomas 'PointedEars' Lahn]

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'})

[…]
In an implementation of similar heuristics, Eclipse JSDT allows function
arguments and variables to be displayed differently. For example, I have
set it up so that it would display argument declarations and references in
bluish italic characters; the identifier in variable declarations in
regular style, but underlined; and local variable references in
normal-colored italic characters. If I were to use your approach, I could
not tell at a glance if an identifier was an argument or a local variable ^ used as
name. I could be ending up assigning to arguments, inadvertently altering
the program flow after that assignment. […]

 

[Frobernik]

Yes. We, the previous subscribers of this newsgroup, have. You should read
a fair amount of past discussions before you post to a newsgroup:

<http://jibbering.com/faq/notes/posting>

Apologies but I (like a lot of others) haven't had the time to read
through the entire back history of this newsgroup from 1995/6-2011 let
alone find the specific thread, post or author to which you're referring

function findPos(obj, name, colour, b, c) {
<snip>
}
findPos({name:'df', colour:'green'})

[…]
In an implementation of similar heuristics, Eclipse JSDT allows function
arguments and variables to be displayed differently. For example, I have
set it up so that it would display argument declarations and references in
bluish italic characters; the identifier in variable declarations in
regular style, but underlined; and local variable references in
normal-colored italic characters. If I were to use your approach, I could
not tell at a glance if an identifier was an argument or a local variable ^ used as
name. I could be ending up assigning to arguments, inadvertently altering
the program flow after that assignment. […]

I use IntelliJ I *don't* use Eclipse - the last time I did it crashed
wiping an entire two days work

Just cause you don't use it doesn't mean to say its doesn't exist. I
don't like the pattern either but the codes smaller

 

[Thomas 'PointedEars' Lahn]

Apologies but I (like a lot of others) haven't had the time to read
through the entire back history of this newsgroup from 1995/6-2011 let
alone find the specific thread, post or author to which you're referring

You are not apologizing; you are rationalizing, and perhaps even trolling.
Fallacy: Reductio ad absurdum. "A fair amount" does not mean "everything".
IIRC, the last discussion on this subject cannot have taken place more than
six months ago. And there are ways to find that discussion quickly (enough
hints have been given), if you really want.

I use IntelliJ I *don't* use Eclipse - the last time I did it crashed
wiping an entire two days work

Few people know how Eclipse advances with each new version, that there is a
new major release every year, and how to configure Eclipse so that it runs
smoothly even with a number of plugins, although the basics are laid out in
the ReadMe.

A single Eclipse crash wiping two days work is doubtful at best. But if
that really happened, you have bigger problems than Eclipse crashes.

Just cause you don't use it doesn't mean to say its doesn't exist.

You are not making sense.

I don't like the pattern either but the codes smaller

That is why it serves code golfing. But small code becoming a purpose in
itself is a recipe for disaster.