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

1740Re: [jslint] New Edition

Expand Messages
  • Luke Page
    Jan 9, 2011
    • 0 Attachment
      I think it is a shame to loose the eqeqeq option :

      We have inherited an extremely large JS codebase. On all new code we use
      eqeqeq, but old code we do not apply it - It is far more difficult to look
      at someone elses code and convert == to === than it is add curly braces,
      correct semi colons, line breaks and indentation. In fact we
      don't recommend it because of the potential for inserting bugs, until that
      code is being re-written or significantly re factored.

      The change makes it impossible for us to convert old code to be nicer in
      incremental steps using JSLint.

      On 8 January 2011 00:17, Douglas Crockford <douglas@...> wrote:

      >
      >
      > I started working on JSLint 10 years ago. It started as a demonstration of
      > a parsing technique [http://javascript.crockford.com/tdop/tdop.html%5d. I
      > intended to then create a JavaScript engine with the compiler and other
      > components written in JavaScript, but the language contained so many design
      > errors that I could not bring myself to replicate them all.
      >
      > So instead I turned the parser into a code quality tool. I thought that
      > syntactic analysis would be sufficient, so I pulled out the code that
      > created the parse tree on the theory that that would make it faster. Such
      > thinking is almost always wrong, as it was indeed in this case. There was no
      > noticeable performance improvement, and I later discovered that a tree could
      > make JSLint even more useful.
      >
      > So I have put the tree back in. You can see the tree by clicking on the
      > [Tree] button. It displays the tree that was produced by the most recent
      > [JSLint] run. I plan to completely change the way JSLint handles line
      > breaking and indentation using that tree. Someday I might also use the tree
      > to write JSMax, the inverse of JSMin.
      >
      > So at the moment, JSLint does not consider indentation or line breakage.
      > That will come later. The only breakage that is checked currently are the
      > cases that are required because of the dreaded semicolon insertion. Breaking
      > with style is a surprisingly difficult problem.
      >
      > Three options are dropped from the new edition. option.immed and
      > option.eqeqeq are now always on. There have proved to be very good
      > practices, so continuing to make them optional is not ultimately beneficial.
      > option.lax is no longer needed.
      >
      > JSLint is now smarter about code paths, so
      >
      > switch (exp) {
      > case 1:
      > if (blah) {
      > return null;
      > } else {
      > return undefined;
      > }
      > case 2:
      > x = 0;
      > break;
      >
      > does not require a break for case 1, but it does require a break for case
      > 2. It is now better able to detect strange loops and other convolutions.
      >
      > This is a big change. All of my code looks good on the new edition, but I
      > haven't tested with yours. If I broke something, please report it. Thank
      > you.
      >
      >
      >


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