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 1 of 3  [1] 2 3  Next page →

#8282 — Difference between findPos("divThis") and findPos(divThis)

I find that either of the two approches below work.I'd appreciate getting a 
little insight into what is going on and the good and bad aspects of each 
approach.Thanksfunction findPos(obj) {
            var w = document.getElementById(obj).offsetWidth;
            var h = document.getElementById(obj).offsetHeight;called with: 
findPos("divThis")Orfunction findPos(obj) {
            var w = obj.offsetWidth;
            var h = obj.offsetHeight;called with: findPos(divThis) 

[toc] | [next] | [standalone]

#8284

Cal Who wrote:

> I find that either of the two approches below work.I'd appreciate getting
> a little insight into what is going on and the good and bad aspects of
> each approach. Thanks
> 
> function findPos(obj)
> {
>   var w = document.getElementById(obj).offsetWidth;
>   var h = document.getElementById(obj).offsetHeight;
> }
> 
> called with: findPos("divThis")
> 
> Or
> 
> function findPos(obj)
> {
>             var w = obj.offsetWidth;
>             var h = obj.offsetHeight;
> }

> called with: findPos(divThis)

Your OP was hard to read and not even syntactically valid; I have 
reformatted it and completed it.  Please take more care next time.

Both approaches work in Internet Explorer and perhaps elsewhere in *Quirks 
Mode*.  That is so because MSHTML, probably to make DOM scripting easier, 
elements with IDs are explicitly represented in the DOM by properties of the 
same name of the object referred to by `window'.

That object (`window' object for short) is in the scope chain.  So if you 
use the `divThis' identifier and no other object in the scope chain has a 
property of that name, it will be resolved to the property of the `window' 
object.  The result is a reference to the DOM element object which 
represents the element.

You should not rely on this proprietary behavior, and you should avoid 
triggering Quirks Mode.

That findPos() function call really is pointless, as the local variables 
will not be visible outside the function here.  So unless you want to 
support IE/MSHTML 4 and NN 4, for which you would need a wrapper function, 
KISS:

  var o = document.getElementById("divThis");
  var w = o.offsetWidth;
  var h = o.offsetHeight;

But do not rely on that either; read the discussion about element dimensions 
three days ago.  (In general: search, read, post.)

BTW, findPos() does not what its name says.


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]

#8286

"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message 
news:4775241.ypaU67uLZW@PointedEars.de...
> Cal Who wrote:
>
>> I find that either of the two approches below work.I'd appreciate getting
>> a little insight into what is going on and the good and bad aspects of
>> each approach. Thanks
>>
>> function findPos(obj)
>> {
>>   var w = document.getElementById(obj).offsetWidth;
>>   var h = document.getElementById(obj).offsetHeight;
         ...
 >>
>> called with: findPos("divThis")
>>
>> Or
>>
>> function findPos(obj)
>> {
>>             var w = obj.offsetWidth;
>>             var h = obj.offsetHeight;
                  ...
 >
>> called with: findPos(divThis)
>
> Your OP was hard to read and not even syntactically valid; I have
> reformatted it and completed it.

Also, I should have included the "..." that (I just added) to make cleared 
that there was more code.

> Both approaches work in Internet Explorer and perhaps elsewhere in *Quirks
> Mode*.  That is so because MSHTML, probably to make DOM scripting easier,
> elements with IDs are explicitly represented in the DOM by properties of 
> the
> same name of the object referred to by `window'.
>
> That object (`window' object for short) is in the scope chain.  So if you
> use the `divThis' identifier and no other object in the scope chain has a
> property of that name, it will be resolved to the property of the `window'
> object.  The result is a reference to the DOM element object which
> represents the element.

I don't have the backgroung to understand the above paragraph.
Is the first approch (var w = document.getElementById(obj).offsetWidth) the 
better one?

>
> You should not rely on this proprietary behavior, and you should avoid
> triggering Quirks Mode.
>
> That findPos() function call really is pointless, as the local variables
> will not be visible outside the function here.  So unless you want to
> support IE/MSHTML 4 and NN 4, for which you would need a wrapper function,
> KISS:
>
>  var o = document.getElementById("divThis");
>  var w = o.offsetWidth;
>  var h = o.offsetHeight;
>
> But do not rely on that either; read the discussion about element 
> dimensions
> three days ago.  (In general: search, read, post.)

I did search. That's where I got the code I asked about.

If you are refering to: "How to Determine Positions of Elements"

I had read it and in fact have copied it and pasted into my file for later 
testing, but he did not, I don't believe, mentioned this method which is 
simpler and since I don't know why I should not rely on it I thought I'd try 
it.

>
> BTW, findPos() does not what its name says.

Good catch but I'm still developing " findPosAndSize"


Thanks


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

#8289

Cal Who wrote:

> "Thomas 'PointedEars' Lahn" wrote […]:
>> Your OP was hard to read and not even syntactically valid; I have
>> reformatted it and completed it.
> 
> Also, I should have included the "..." that (I just added) to make cleared
> that there was more code.

ACK.

>> Both approaches work in Internet Explorer and perhaps elsewhere in
>> *Quirks Mode*.  That is so because MSHTML, probably to make DOM scripting
>> easier, elements with IDs are explicitly represented in the DOM by
>> properties of the same name of the object referred to by `window'.
>>
>> That object (`window' object for short) is in the scope chain.  So if you
>> use the `divThis' identifier and no other object in the scope chain has a
>> property of that name, it will be resolved to the property of the
>> `window' object.  The result is a reference to the DOM element object
>> which represents the element.
> 
> I don't have the backgroung to understand the above paragraph.

I will answer specific, *smart* questions you may have.  (So do not ask,
for example, "What is a scope chain?", unless you want a "STFW" answer.)

<http://www.catb.org/~esr/faqs/smart-questions.html>

But I will still ignore you if you (continue to) post with an invalid 
From/Reply-To header field value.  Usenet can only work if communication 
works both ways.

> Is the first approch (var w = document.getElementById(obj).offsetWidth)
> the better one?

Yes and no.  It is the better one if you pass the element's ID string for 
`obj'.  It is not better if you call document.getElementById(obj) twice in 
the process.  There are also cases where you do not need to call 
document.getElementById(); in that case it would be better not to call it.

> If you are refering to: "How to Determine Positions of Elements"

I was referring to the thread started with 
<news:bd12b66f-33f5-43d2-8e22-6f81b42c3d8b@n14g2000vbn.googlegroups.com>, 
Subject "David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How 
to Measure Element Dimensions", which is what your posted code does.

> I had read it and in fact have copied it and pasted into my file for later
> testing, but he did not, I don't believe, mentioned this method which is
> simpler and since I don't know why I should not rely on it I thought I'd
> try it.

Your posted code has nothing to do with the posting you are referring to.


Please trim your quotes to the relevant minimum next time.

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

HTH

PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

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

#8292

 >
> But I will still ignore you if you (continue to) post with an invalid
> From/Reply-To header field value.  Usenet can only work if communication
> works both ways.

I have no idea what it is about. I use IE Express and reply with "Reply 
Group"
Do I have something set up wrong?
'
>
>> Is the first approch (var w = document.getElementById(obj).offsetWidth)
>> the better one?
>
> Yes and no.  It is the better one if you pass the element's ID string for
> `obj'.  It is not better if you call document.getElementById(obj) twice in
> the process.  There are also cases where you do not need to call
> document.getElementById(); in that case it would be better not to call it.
>

That's what I'll do then.

Thanks 

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

#8293

On 13/11/2011 18:04,  Cal Who wrote:
>   >
>> But I will still ignore you if you (continue to) post with an invalid
>> From/Reply-To header field value.  Usenet can only work if communication
>> works both ways.
>
> I have no idea what it is about. I use IE Express and reply with "Reply
> Group"
> Do I have something set up wrong?
> '
>>
>>> Is the first approch (var w = document.getElementById(obj).offsetWidth)
>>> the better one?
>>
>> Yes and no.  It is the better one if you pass the element's ID string for
>> `obj'.  It is not better if you call document.getElementById(obj) twice in
>> the process.  There are also cases where you do not need to call
>> document.getElementById(); in that case it would be better not to call it.
>>
>
> That's what I'll do then.
>
> Thanks
>
>

I always use obj as a reference to an element of the DOM. But I admit 
there are cases in which you would like to receive either a string or an 
element reference as the function's argument. In this case, try this code:

function getOuterDimensions(obj) {
   var el = (typeof obj == 'string') ? document.getElementById(obj) :
            obj,
   w = el.offsetWidth;
   h = el.offsetHeight;
   ...

}

Please, have a look at the post called "David Mark's Javascript Tip Du 
Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions".

-- 
Joao Rodrigues (J.R.)

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

#8294

On 13/11/2011 18:55, J.R. wrote:
> On 13/11/2011 18:04, Cal Who wrote:
>> >
>>> But I will still ignore you if you (continue to) post with an invalid
>>> From/Reply-To header field value. Usenet can only work if communication
>>> works both ways.
>>
>> I have no idea what it is about. I use IE Express and reply with "Reply
>> Group"
>> Do I have something set up wrong?
>> '
>>>
>>>> Is the first approch (var w = document.getElementById(obj).offsetWidth)
>>>> the better one?
>>>
>>> Yes and no. It is the better one if you pass the element's ID string for
>>> `obj'. It is not better if you call document.getElementById(obj)
>>> twice in
>>> the process. There are also cases where you do not need to call
>>> document.getElementById(); in that case it would be better not to
>>> call it.
>>>
>>
>> That's what I'll do then.
>>
>> Thanks
>>
>>
>
> I always use obj as a reference to an element of the DOM. But I admit
> there are cases in which you would like to receive either a string or an
> element reference as the function's argument. In this case, try this code:
>
> function getOuterDimensions(obj) {
> var el = (typeof obj == 'string') ? document.getElementById(obj) :
> obj,
> w = el.offsetWidth;
> h = el.offsetHeight;
> ...
>
> }
>

Correcting a typo:

   var el = (typeof obj == 'string') ? document.getElementById(obj) :
           obj,
       w = el.offsetWidth, // , instead of ;
       h = el.offsetHeight;

> Please, have a look at the post called "David Mark's Javascript Tip Du
> Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions".
>

-- 
Joao Rodrigues (J.R.)

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

#8295

 >
>   var el = (typeof obj == 'string') ? document.getElementById(obj) :
>           obj,
>       w = el.offsetWidth, // , instead of ;
>       h = el.offsetHeight;
>
 That's neat.

Except for the commas!

I looked up comma operator but am still confused.

Wouldn't this be OK (better?)

var el = (typeof obj == 'string') ? document.getElementById(obj) : obj;
       w = el.offsetWidth ;
       h = el.offsetHeight;
      ...

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

#8296

On 13/11/2011 20:10,  Cal Who wrote:
>   >
>>    var el = (typeof obj == 'string') ? document.getElementById(obj) :
>>            obj,
>>        w = el.offsetWidth, // , instead of ;
>>        h = el.offsetHeight;
>>
>   That's neat.
>
> Except for the commas!
>
> I looked up comma operator but am still confused.
>
> Wouldn't this be OK (better?)
>
> var el = (typeof obj == 'string') ? document.getElementById(obj) : obj;
>         w = el.offsetWidth ;
>         h = el.offsetHeight;
>        ...
>

No, because the ";" marks the end of the variable declaration list. In 
the above code, you are indeed creating an implied global variable 
called h, instead of creating a private variable in the function scope.

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;

-- 
Joao Rodrigues (J.R.)

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

#8299

"J.R." <groups_jr-1@yahoo.com.br> wrote in message 
news:j9phhk$s3i$1@speranza.aioe.org...
> On 13/11/2011 20:10,  Cal Who wrote:
>>   >
>>>    var el = (typeof obj == 'string') ? document.getElementById(obj) :
>>>            obj,
>>>        w = el.offsetWidth, // , instead of ;
>>>        h = el.offsetHeight;
>>>
>>   That's neat.
>>
>> Except for the commas!
>>
>> I looked up comma operator but am still confused.
>>
>> Wouldn't this be OK (better?)
>>
>> var el = (typeof obj == 'string') ? document.getElementById(obj) : obj;
>>         w = el.offsetWidth ;
>>         h = el.offsetHeight;
>>        ...
>>
>
> No, because the ";" marks the end of the variable declaration list. In the 
> above code, you are indeed creating an implied global variable called h, 
> instead of creating a private variable in the function scope.
>
> 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;
>
> -- 
> Joao Rodrigues (J.R.)


Thanks a lot

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

#8300

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.

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.

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

Rgds

Denis McMahon

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

#8304

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.

> 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:
- there's a single place to look for all the local variables needed by 
the function;
- prevention of logical errors when a variable is used before it’s defined;
- Helps you remember to declare variables and therefore minimize globals;
- only one var statement means less code to type and a reduction in the 
file size.


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

-- 
Joao Rodrigues (J.R.)

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

#8313

On Mon, 14 Nov 2011 03:14:20 -0200, J.R. wrote:

> The advantages of using the Single var Pattern at the top of your
> functions are:

I'm not objecting to the suggestion that best practice includes defining 
all your variables with var statements at the start of a function. I 
agree that this is indeed best practice.

I am, however, objecting to (a) your assertion that it "must" be done, or 
(b) that best practice requires the use of a single var statement.

Rgds

Denis McMahon

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

#8319

On 14/11/2011 12:03, Denis McMahon wrote:
> On Mon, 14 Nov 2011 03:14:20 -0200, J.R. wrote:
>
>> The advantages of using the Single var Pattern at the top of your
>> functions are:
>
> I'm not objecting to the suggestion that best practice includes defining
> all your variables with var statements at the start of a function. I
> agree that this is indeed best practice.
>
> I am, however, objecting to (a) your assertion that it "must" be done, or
> (b) that best practice requires the use of a single var statement.


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

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

Cheers,
Joao Rodrigues (J.R.)

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

#8332

On Mon, 14 Nov 2011 14:14:50 -0200, J.R. wrote:

> On 14/11/2011 12:03, Denis McMahon wrote:
>> On Mon, 14 Nov 2011 03:14:20 -0200, J.R. wrote:
>>
>>> The advantages of using the Single var Pattern at the top of your
>>> functions are:
>>
>> I'm not objecting to the suggestion that best practice includes
>> defining all your variables with var statements at the start of a
>> function. I agree that this is indeed best practice.
>>
>> I am, however, objecting to (a) your assertion that it "must" be done,
>> or (b) that best practice requires the use of a single var statement.

> 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

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

#8333

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;

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#8344

On Mon, 14 Nov 2011 18:36:46 +0000, Evertjan. wrote:

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

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

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

#8339

Denis McMahon wrote:
> 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

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

#8345

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},
> {s:'mule',x:'neuter',a:1}],
>    /* ... */;
<snip>
> ... .  Richard's argument against the comma are reasonable, ...
<snip>

;-)

Richard.

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

#8366

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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web