Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #8326
| From | Richard Cornford <Richard@litotes.demon.co.uk> |
|---|---|
| Newsgroups | comp.lang.javascript |
| Subject | Re: Difference between findPos("divThis") and findPos(divThis) |
| Date | 2011-11-14 09:18 -0800 |
| Organization | http://groups.google.com |
| Message-ID | <25fbd29a-4b62-42c7-8082-e6ae79c5eb7b@p16g2000yqd.googlegroups.com> (permalink) |
| References | (6 earlier) <j9pb43$ah2$2@speranza.aioe.org> <j9pf87$rka$1@dont-email.me> <j9phhk$s3i$1@speranza.aioe.org> <4ec07ef1$0$28711$a8266bb1@newsreader.readnews.com> <j9q83e$b9m$1@speranza.aioe.org> |
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.
Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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