Loading ...
Sorry, an error occurred while loading the content.

2037Re: [jslint] Re: has not been fully defined yet

Expand Messages
  • Kent Davidson
    Mar 9, 2011
    • 0 Attachment
      Good advice, bad advice. Matter of opinion. If you think it's bad advice, then ignore that warning. I set up my scripts to run through a local copy of jslint for testing. Any errors produced are considered blocking for shipping new versions. If I don't like a warning, I code the test to ignore the warning. You should do the same.

      I agree, Douglas could go and rewrite his parsing engine to discover and detect when anonymous functions declared and assigned to the same var that are used within the function itself are OK, but in all honestly, it's debatable whether it will work correctly or in all cases. I'm sure there's some theoretical proof of closure to determine if using a variable in a function produces an unintended side effect.

      I'm more of an engineer, than a researcher. I test with 50+ browsers when I ship JS code. So, given that I have to work with the least common denominator, I tend to err on the side of being more conservative.

      Hence I think the absolute rule that in general, it's safer to simply declare the variable, then use it.

      Whenever I work in any language, I turn all lint options on their highest levels. Any warning/error/notice sometimes shows an error. I also tend to trust that most lint tools do find errors more often than they cramp developers style.

      That said, Douglas has his own style and advice regarding JavaScript which he has emblazoned on jslint and his personal site. I have read a lot of it, and I gotta say, he's not a complete buffoon. Pretty much the opposite.

      If you disagree, I completely respect that. However, given his experience, and the fact that he wrote a lint program in JavaScript, I tend to follow his advice.

      Not to be a sycophant, but I just have gratitude for the work put into this tool.

      Cheers,

      -Kent.

      On Mar 9, 2011, at 2:46 PM, John Hawkinson wrote:

      > Kent Davidson <kent@...> wrote on Wed, 9 Mar 2011
      > at 14:12:41 -0500 in <46D9D4DF-08B8-4820-AE1F-179966621208@...>:
      >
      > > Which is an error, unless you want it to be "undefined".
      > > The solution is simply to add a semicolon and repeat the variable.
      >
      > Wait, is this not bad advice?
      >
      > You are rewriting the code from a form JSLint detects as bad to a form
      > that is equally bad, but escapes JSLint's detection because it is too
      > hard to detect. In essence, you are encouraging programmers to defeat
      > the limited forms of checking we have with a construct that can easily
      > evolve later. Especially in Javascript where we lack block scope and
      > JSLint encourages us (onevar: true) to declare variables far from
      > their point of use.
      >
      > > var pdfdone;
      > > pdfdone = doc.eventListeners.add("afterExport", function(e) {
      > > if (e.format==="whatever") {
      > > pdfdone.remove();
      > > }
      >
      > This seems a classic case of the Law of Unintended Consequences. JSLint
      > encouraging us to write code it cannot check to defeat its warning?
      >
      > In what's ironic, though, I had actually misinterpretted the problem
      > in my actual code, because it actually did separate the declaration
      > from point-of-use. But there was a typo in the declaration so the
      > variable was implicitly global, and when I built a small test-case to
      > understand JSLint's behavior, I inadvertantly fixed the typo.
      >
      > --jhawk@...
      > John Hawkinson
      >



      [Non-text portions of this message have been removed]
    • Show all 24 messages in this topic