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

1747Re: New Edition

Expand Messages
  • Jordan
    Jan 10, 2011
      Removing the eqeqeq and immed option prevents me from being able to use things such as:
      var ie = "\v"=="v"; per http://ajaxian.com/archives/ievv
      as well as a one-line browser selector:
      (function x(){})[-5]=='x'?'FF3':(function x(){})[-6]=='x'?'FF2':/a/[-1]=='a'?'FF':'\v'=='v'?'IE':/a/.__proto__=='//'?'Saf':/s/.test(/a/.toString)?'Chr':!!window.opera?'Op':'Unknown';
      per http://www.thespanner.co.uk/2009/01/29/detecting-browsers-javascript-hacks/

      These may be hacks, and I always try to avoid using them, but I've found them necessary for dealing with certain browser behaviors, and more useful than user-agent sniffing. I certainly appreciate that these options should be set for all new code and 99% of old code, but the benefit of having them as options means I can set jslint directives in my file, and continue to easily validate.

      If you are going to insist on removing these configuration options, perhaps could you add a web get parameter so I can view the website with the latest version of jslint that offers these options?

      - Jordan

      --- In jslint_com@yahoogroups.com, "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.
      >
    • Show all 12 messages in this topic