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

Discussion in 'Javascript' started by Cal Who, Nov 13, 2011.

  1. No. What happens is what I described, which is compliant with ECMAScript
    Edition 3 Final, sections 11.13.1 and 8.6.2, and Editions 5 and 5.1,
    sections 11.13.1 and 8.7.2, respectively.
    The current edition of ECMAScript is 5.1, June 2011 CE; not Edition 3
    (Final), December 1999/March 2000 CE.
    That section's second sentence refers to *variable statements* outside of a
    FunctionDeclaration, as made obvious by its first sentence.
    No, a "variable defined *with* function-local scope" is something else than
    "a variable defined *in* the function-local scope" (which you also did not
    say before). The proper term for such a variable is _local_ variable, _not_
    a "private" variable (whereas you said the latter before).
    Please name a counter-example using ECMAScript-conforming code where a
    `private'-like property visibility is achieved explicitly.
    No, it is wrong to say "must not use". "Must not" in English means "is not
    allowed to". It is certainly allowed to use that syntactical construct, as
    it constitutes nothing more than consecutive statements.
    That is not what you said before.
    That is also not what you said before.
    Will you please at least *try* get yourself educated before you post?
    Eclipse JSDT is the Eclipse _JavaScript_ Development Tools plugin.
    Yes, it matters how a commonly used JavaScript IDE can deal with either of
    those syntactical constructs.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Nov 14, 2011
    #21
    1. Advertisements

  2. Cal Who

    Eric Bednarz Guest

    RTFM. Anyhow, the earlier everybody exclusively uses the single var
    pattern, the earlier the shitty Eclipse JSDT will get fixed. :)
     
    Eric Bednarz, Nov 14, 2011
    #22
    1. Advertisements

  3. Cal Who

    J.R. Guest

    I still have a long and winding road to go until I get a thorough
    comprehension about JavaScript. But what about you?
    No, I am not.
    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.
    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.
    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.
    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.
     
    J.R., Nov 14, 2011
    #23
  4. <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.

    That would be ridiculously dogmatic of them.

    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.
    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.
    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).
    This is not an advantage over multiple consecutive variable
    declaration statements at the top of that same function.
    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.
    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.
    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.
    Do you really know that? (and should it matter anyway as in isolation
    that would only make for an argument from authority?)
    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?
    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.
     
    Richard Cornford, Nov 14, 2011
    #24
  5. 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.
    Apparently you don't even know what you write.
    Not to you, obviously, as you were claiming that your approach would save
    space. It doesn't.
    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.
    Says who? The same person who says you must not use consecutive variable
    statements? I see.
    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
     
    Thomas 'PointedEars' Lahn, Nov 14, 2011
    #25
  6. Cal Who

    J.R. Guest

    I would not say one person, but *many* experienced and renowned JS
    developers and all major browser-vendors. Google and find by yourself.
    LOL. Very entertaining.
     
    J.R., Nov 14, 2011
    #26
  7. There we have the "ipse dixit" fallacy again.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Nov 14, 2011
    #27
  8. Cal Who

    J.R. Guest

    Yes, I do.
    No, it shouldn't matter because of the "fallacy of authority"
    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.
     
    J.R., Nov 14, 2011
    #28
  9. Yep, read that.
    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
     
    Denis McMahon, Nov 14, 2011
    #29
  10. Cal Who

    Evertjan. Guest

    Denis McMahon wrote on 14 nov 2011 in comp.lang.javascript:
    This is not the same as:

    var f;
    var g;
    var e = f = g = 0;
     
    Evertjan., Nov 14, 2011
    #30
  11. 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
     
    Denis McMahon, Nov 14, 2011
    #31
  12. Cal Who

    J.R. Guest

    No, it is more like "vox populi, vox Dei"...
     
    J.R., Nov 14, 2011
    #32
  13. IOW: Faith, not science. I rest my case.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Nov 14, 2011
    #33
  14. Cal Who

    Scott Sauyet Guest

    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
     
    Scott Sauyet, Nov 14, 2011
    #34
  15. Exaggerating to make a point is an anti-pattern of its own. It
    means that anyone reading what you write can not simply take it at
    face value, but now has to figure out whether the meaning to use is
    the literal one or a weaker form of it.

    [snip]

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Nov 14, 2011
    #35
  16. In fact, it might be a disadvantage! Consider:
    var a="somthing",
    b="another"
    c="YA"
    which is correct but misleading code. c is not declared here. What
    was intended was:
    var a="somthing",
    b="another",
    c="YA"
    (added a comma to the second line)
    I would rather type var a few more times and feel safer about my
    code. See my example above. Sir Hoare said it well:

    "I was eventually persuaded of the need to design programming
    notations so as to maximize the number of errors which cannot be made,
    or if made, can be reliably detected at compile time. Perhaps this
    would make the text of programs longer. Never mind! Wouldn't you be
    delighted if your Fairy Godmother offered to wave her wand over your
    program to remove all its errors and only made the condition that you
    should write out and key in your whole program three times!"

    [snip]
    Quite.

    [snip]

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Nov 14, 2011
    #36
  17. 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
     
    Denis McMahon, Nov 15, 2011
    #37
  18. Cal Who

    Scott Sauyet Guest

    Perhaps I should have said "are eminently reasonable"." :)

    -- Scott
     
    Scott Sauyet, Nov 16, 2011
    #38
  19. Cal Who

    Frobernik Guest

    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
     
    Frobernik, Nov 17, 2011
    #39
  20. (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
    --
    Not with javascript. Nonsense propagates like wildfire in this field.
    -- Richard Cornford, comp.lang.javascript, 2011-11-14
     
    Thomas 'PointedEars' Lahn, Nov 17, 2011
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.