Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #8282 > unrolled thread

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

Back to article view | Back to comp.lang.javascript

Contents

  Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 09:51 -0500
    Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 18:25 +0100
      Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 13:58 -0500
        Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 20:26 +0100
          Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 15:04 -0500
            Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 18:55 -0200
              Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 18:59 -0200
                Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 17:10 -0500
                  Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 20:49 -0200
                    Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 20:00 -0500
                    Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 02:37 +0000
                      Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 03:14 -0200
                        Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 14:03 +0000
                          Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 14:14 -0200
                            Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 18:31 +0000
                              Re: Difference between findPos("divThis") and findPos(divThis) "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-11-14 18:36 +0000
                                Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-15 00:18 +0000
                              Re: Difference between findPos("divThis") and findPos(divThis) Scott Sauyet <scott.sauyet@gmail.com> - 2011-11-14 10:54 -0800
                                Re: Difference between findPos("divThis") and findPos(divThis) "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-15 01:23 +0000
                                  Re: Difference between findPos("divThis") and findPos(divThis) Scott Sauyet <scott.sauyet@gmail.com> - 2011-11-16 06:04 -0800
                                    Re: Difference between findPos("divThis") and findPos(divThis) Frobernik <nospam@nospam.com> - 2011-11-17 22:06 +0000
                                      Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-17 23:54 +0100
                                        Re: Difference between findPos("divThis") and findPos(divThis) Frobernik <nospam@nospam.com> - 2011-11-18 09:33 +0000
                                          Function arguments vs. local variables (was: Difference between findPos("divThis") and findPos(divThis)) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-19 16:05 +0100
                                            Re: Function arguments vs. local variables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-19 18:17 +0100
                                              Re: Function arguments vs. local variables Frobernik <nospam@nospam.com> - 2011-11-21 20:01 +0000
                                                Re: Function arguments vs. local variables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-22 12:50 +0100
                        Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 15:04 +0100
                          Re: Difference between findPos("divThis") and findPos(divThis) John G Harris <john@nospam.demon.co.uk> - 2011-11-14 15:13 +0000
                            Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 18:27 +0100
                          Re: Difference between findPos("divThis") and findPos(divThis) Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-14 17:52 +0100
                          Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 15:07 -0200
                            Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 18:19 +0100
                              Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 15:44 -0200
                                Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 19:01 +0100
                                  Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 16:42 -0200
                                    Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 19:53 +0100
                        Re: Difference between findPos("divThis") and findPos(divThis) Richard Cornford <Richard@litotes.demon.co.uk> - 2011-11-14 09:18 -0800
                          Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 16:22 -0200
                          Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 18:38 +0000
                          Re: Difference between findPos("divThis") and findPos(divThis) Gene Wirchenko <genew@ocis.net> - 2011-11-14 12:12 -0800
                        Re: Difference between findPos("divThis") and findPos(divThis) Gene Wirchenko <genew@ocis.net> - 2011-11-14 12:00 -0800
                      Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-14 08:48 -0500
                    Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 13:15 +0100
                      Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 13:03 -0200
                        Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 17:24 +0100
            Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 13:00 +0100
          Re: Difference between findPos("divThis") and findPos(divThis) John G Harris <john@nospam.demon.co.uk> - 2011-11-14 15:05 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#8394

On 16/11/2011 14:04, Scott Sauyet wrote:
> Richard Cornford wrote:
>> Scott Sauyet wrote:
>>> Denis McMahon wrote:
>>>> Minimisation is good, but the following:
>>
>>>> var a = "df";
>>>> var b = 17;
>> <snip>
>>> Another contender is this:
>>
>>> var a = "df",
>>>      b = 17;
>>
>>              ^ oops!
>>
>>>      c = [{s:'monkey',x:'male',a:3},{s:'elephant',x:'female',a:7},
>> <snip>
>>> ... .  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

[toc] | [prev] | [next] | [standalone]

#8397

Frobernik wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#8402

On 17/11/2011 22:54, Thomas 'PointedEars' Lahn wrote:
> Frobernik wrote:
>> 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

[toc] | [prev] | [next] | [standalone]

#8423 — Function arguments vs. local variables (was: Difference between findPos("divThis") and findPos(divThis))

Frobernik wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Frobernik wrote:
>>> 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:

<http://jibbering.com/faq/notes/posting>
 
>> 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

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
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#8425 — Re: Function arguments vs. local variables

Thomas 'PointedEars' Lahn wrote:

>> Frobernik wrote:
>>> 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.  […]

[toc] | [prev] | [next] | [standalone]

#8516 — Re: Function arguments vs. local variables

On 19/11/2011 15:05, Thomas 'PointedEars' Lahn wrote:
 > Frobernik wrote:
 >>>> 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:
 >
 > <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

[toc] | [prev] | [next] | [standalone]

#8524 — Re: Function arguments vs. local variables

Frobernik wrote:

> On 19/11/2011 15:05, Thomas 'PointedEars' Lahn wrote:
>> Frobernik wrote:
>>>>> 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:
>>
>> <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

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.

-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#8314

J.R. wrote:

> On 14/11/2011 00:37, Denis McMahon wrote:
>> On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote:
>>> it is one of the JavaScript best practices to declare all of the
>>> variables used in a function at the top of the function body. You may
>>> have many variables separated by commas, e.g
>>
>>>     var el = ...,
>>>         h = ...,
>>>         w = ...,
>>>         i, j, len, ..., z;
>>
>>> You must not use multiple var statements such as:
>>>     var el;
>>>     var h = ...;
>>>     var z;
>>
>> 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.

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").
 
>> Some people think all variables should be declared in a single statement.
>> Some people use a different statement for each type of variable, where
>> type is the sort of data that it will be used to hold (array, string,
>> integer, float, object etc).
>> Some people just use one variable per var.
> 
> The advantages of using the Single var Pattern at the top of your
> functions are:

You are confusing two concepts here.

> - there's a single place to look for all the local variables needed by
> the function;

The comma operator does not help with this.

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

The comma operator does not help with this.

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

The comma …

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

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;

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:

awk '
  BEGIN {
    total = 0;
    var_lines = 0;
    print;
  }

  /^[[:space:]]*var/ {
    total += length();
    var_lines++;
  }

  END {
    print "LOCs: " NR;
    print "var LOCs: " var_lines;
    print "avg(length(var LOCs)): " total/var_lines " bytes";
    savings = 2 * var_lines;
    print "Potential savings (best case): " savings " bytes (2 * " var_lines 
")";
    "wc -c " FILENAME | getline wc_out;
    split(wc_out, data);
    filesize = data[1];
    print "File size: " filesize " bytes";
    print "Potential savings (best case): " savings/filesize * 100 " %";
  }' \
  object.js 

LOCs: 2009
var LOCs: 66
avg(length(var LOCs)): 27.8788 bytes
Potential savings (best case): 132 bytes (2 * 66)
File size: 55694 bytes
Potential savings (best case): 0.237009 %
----

2 bytes per `var' line because changing

  var.foo;\n
  var.bar;\n

to

  var.foo,\n
  ..bar;\n

saves two characters on the second, third etc. line per variable 
declaration.  However, it should be noted that the more readable form is

  var\n
  ..foo,\n
  ..bar;\n

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

With tab indentation, it is a change of

  var.foo;\n
  var.bar;\n

to

  var\n
  <HT>foo,\n
  <HT>bar;\n

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

>> These are all permitted by the various standards, and they all work.
>> There is no reason that you "must" or "must not" do any of these.
>>
>> Also, "best practice" is invariably "in the opinion of the author of the
>> website / book / blog / whatever" that said example of best practice
>> appears in.
> 
> 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>
> 
> 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...
> 
>> As a matter of interest, what's your reference for "best
>> practice"? If I write a book or start a blog called "Javascript - Best
>> Practice" does that make it true?
> 
> No, it doesn't, although I know you're a very experienced and smart
> programmer. However, if you published some evidence such as performance
> tests, etc., then you could state that some practice should be either
> considered a good one or avoided altogether.

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


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#8322

On Mon, 14 Nov 2011 at 15:04:54, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>J.R. wrote:

  <snip>
>> - there's a single place to look for all the local variables needed by
>> the function;
>
>The comma operator does not help with this.
  <snip>

It's not the comma *operator* here; that can only separate expressions.
The commas here are just part of the syntax of a variable declaration
list.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#8328

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> J.R. wrote:
>>> - there's a single place to look for all the local variables needed by
>>> the function;
>> The comma operator does not help with this.
> 
> It's not the comma *operator* here; that can only separate expressions.
> The commas here are just part of the syntax of a variable declaration
> list.

ACK, thanks.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#8324

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

>>> On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote:
>>>> it is one of the JavaScript best practices to declare all of the
>>>> variables used in a function at the top of the function body. You may
>>>> have many variables separated by commas, e.g
>>>
>>>>     var el = ...,
>>>>         h = ...,
>>>>         w = ...,
>>>>         i, j, len, ..., z;

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

[toc] | [prev] | [next] | [standalone]

#8325

On 14/11/2011 12:04, Thomas 'PointedEars' Lahn wrote:
> J.R. wrote:
>
>> On 14/11/2011 00:37, Denis McMahon wrote:
>>> On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote:
>>>> it is one of the JavaScript best practices to declare all of the
>>>> variables used in a function at the top of the function body. You may
>>>> have many variables separated by commas, e.g
>>>
>>>>      var el = ...,
>>>>          h = ...,
>>>>          w = ...,
>>>>          i, j, len, ..., z;
>>>
>>>> You must not use multiple var statements such as:
>>>>      var el;
>>>>      var h = ...;
>>>>      var z;
>>>
>>> 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.
>
> 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?

>>> Some people think all variables should be declared in a single statement.
>>> Some people use a different statement for each type of variable, where
>>> type is the sort of data that it will be used to hold (array, string,
>>> integer, float, object etc).
>>> Some people just use one variable per var.
>>
>> The advantages of using the Single var Pattern at the top of your
>> functions are:
>
> You are confusing two concepts here.

No, I am not.

>
>> - there's a single place to look for all the local variables needed by
>> the function;
>
> The comma operator does not help with this.
>
>> - prevention of logical errors when a variable is used before it’s
>> defined;
>
> 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.

>> - Helps you remember to declare variables and therefore minimize
>> globals;
>
> The comma …
>
>> - only one var statement means less code to type and a reduction
>> in the file size.
>
> 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.

>
>>> These are all permitted by the various standards, and they all work.
>>> There is no reason that you "must" or "must not" do any of these.
>>>
>>> Also, "best practice" is invariably "in the opinion of the author of the
>>> website / book / blog / whatever" that said example of best practice
>>> appears in.
>>
>> 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>
>>
>> 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...
>>
>>> As a matter of interest, what's your reference for "best
>>> practice"? If I write a book or start a blog called "Javascript - Best
>>> Practice" does that make it true?
>>
>> No, it doesn't, although I know you're a very experienced and smart
>> programmer. However, if you published some evidence such as performance
>> tests, etc., then you could state that some practice should be either
>> considered a good one or avoided altogether.
>
> 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.

-- 
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#8327

J.R. wrote:

> On 14/11/2011 12:04, Thomas 'PointedEars' Lahn wrote:
>> J.R. wrote:
>>> On 14/11/2011 00:37, Denis McMahon wrote:
>>>> On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote:
>>>>> it is one of the JavaScript best practices to declare all of the
>>>>> variables used in a function at the top of the function body. You may
>>>>> have many variables separated by commas, e.g
>>>>
>>>>>      var el = ...,
>>>>>          h = ...,
>>>>>          w = ...,
>>>>>          i, j, len, ..., z;
>>>>
>>>>> You must not use multiple var statements such as:
>>>>>      var el;
>>>>>      var h = ...;
>>>>>      var z;
>>>>
>>>> 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.
>>
>> 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?
> 
>>>> Some people think all variables should be declared in a single
>>>> statement. Some people use a different statement for each type of
>>>> variable, where type is the sort of data that it will be used to hold
>>>> (array, string, integer, float, object etc).
>>>> Some people just use one variable per var.
>>>
>>> The advantages of using the Single var Pattern at the top of your
>>> functions are:
>>
>> You are confusing two concepts here.
> 
> 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.

>>> - there's a single place to look for all the local variables needed by
>>> the function;
>>
>> The comma operator does not help with this.
>>
>>> - prevention of logical errors when a variable is used before it’s
>>> defined;
>>
>> 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.

Apparently you don't even know what you write.

>>> - Helps you remember to declare variables and therefore minimize
>>> globals;
>>
>> The comma …
>>
>>> - only one var statement means less code to type and a reduction
>>> in the file size.
>>
>> 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.

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
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#8329

On 14/11/2011 15:19, Thomas 'PointedEars' Lahn wrote:

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

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.

-- 
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#8330

J.R. wrote:

> On 14/11/2011 15:19, Thomas 'PointedEars' Lahn wrote:
>>> 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.
> 
> 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
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#8335

On 14/11/2011 16:01, Thomas 'PointedEars' Lahn wrote:
> J.R. wrote:
>
>> On 14/11/2011 15:19, Thomas 'PointedEars' Lahn wrote:
>>>> 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.
>>
>> 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.

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

-- 
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#8337

J.R. wrote:

> On 14/11/2011 16:01, Thomas 'PointedEars' Lahn wrote:
>> J.R. wrote:
>>> On 14/11/2011 15:19, Thomas 'PointedEars' Lahn wrote:
>>>>> 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.
>>> 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.
> 
> No, it is more like "vox populi, vox Dei"...

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


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#8326

On Nov 14, 5:14 am, J.R. wrote:
> On 14/11/2011 00:37, Denis McMahon wrote:
>> On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote:
>
>>> it is one of the JavaScript best practices to declare all of the
>>> variables used in a function at the top of the function body. You
>>> may have many variables separated by commas, e.g
>
>>>     var el = ...,
>>>         h = ...,
>>>         w = ...,
>>>         i, j, len, ..., z;
>
>>> You must not use multiple var statements such as:
>>>     var el;
>>>     var h = ...;
>>>     var z;
>
>> 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.

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

>> Some people think all variables should be declared in a single
>> statement.

That would be ridiculously dogmatic of them.

>> Some people use a different statement for each type
>> of variable, where type is the sort of data that it will be used
>> to hold (array, string, integer, float, object etc).
>> Some people just use one variable per var.

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.

>> These are all permitted by the various standards, and they all
>> work. There is no reason that you "must" or "must not" do any
>> of these.
>
>> Also, "best practice" is invariably "in the opinion of the author
>> of the website / book / blog / whatever" that said example of best
>> practice appears in.
>
> 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.

>> As a matter of interest, what's your reference for "best
>> practice"? If I write a book or start a blog called "Javascript
>> - Best Practice" does that make it true?
>
> 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.

[toc] | [prev] | [next] | [standalone]

#8331

On 14/11/2011 15:18, Richard Cornford wrote:
> On Nov 14, 5:14 am, J.R. wrote:
>> On 14/11/2011 00:37, Denis McMahon wrote:
>>> On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote:
>>
>>>> it is one of the JavaScript best practices to declare all of the
>>>> variables used in a function at the top of the function body. You
>>>> may have many variables separated by commas, e.g
>>
>>>>      var el = ...,
>>>>          h = ...,
>>>>          w = ...,
>>>>          i, j, len, ..., z;
>>
>>>> You must not use multiple var statements such as:
>>>>      var el;
>>>>      var h = ...;
>>>>      var z;
>>
>>> 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.
>
> <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.
>
>>> Some people think all variables should be declared in a single
>>> statement.
>
> That would be ridiculously dogmatic of them.
>
>>> Some people use a different statement for each type
>>> of variable, where type is the sort of data that it will be used
>>> to hold (array, string, integer, float, object etc).
>>> Some people just use one variable per var.
>
> 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.
>
>>> These are all permitted by the various standards, and they all
>>> work. There is no reason that you "must" or "must not" do any
>>> of these.
>>
>>> Also, "best practice" is invariably "in the opinion of the author
>>> of the website / book / blog / whatever" that said example of best
>>> practice appears in.
>>
>> 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.
>
>>> As a matter of interest, what's your reference for "best
>>> practice"? If I write a book or start a blog called "Javascript
>>> - Best Practice" does that make it true?
>>
>> No, it doesn't, although I know you're a very experienced and
>> smart programmer.
>
> 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" 
<http://www.constitution.org/col/logical_fallacies.htm>

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

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.

-- 
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#8334

On Mon, 14 Nov 2011 09:18:09 -0800, Richard Cornford wrote:
> Joao Rodrigues (J.R.) wrote:
>> Denis McMahon wrote:

>>> As a matter of interest, what's your reference for "best practice"? If
>>> I write a book or start a blog called "Javascript - Best Practice"
>>> does that make it true?

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

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web