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

Groups > comp.lang.javascript > #8331

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

Show all headers | View raw

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

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web