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

New Edition

Expand Messages
  • Douglas Crockford
    I started working on JSLint 10 years ago. It started as a demonstration of a parsing technique [http://javascript.crockford.com/tdop/tdop.html]. I intended to
    Message 1 of 12 , Jan 7, 2011
    • 0 Attachment
      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.
    • Felix E. Klee
      On Sat, Jan 8, 2011 at 1:17 AM, Douglas Crockford ... In fact that s a very good omission. The last version would report that the following code is not
      Message 2 of 12 , Jan 8, 2011
      • 0 Attachment
        On Sat, Jan 8, 2011 at 1:17 AM, Douglas Crockford
        <douglas@...> wrote:
        > at the moment, JSLint does not consider indentation

        In fact that's a very good omission. The last version would report that
        the following code is not properly indented. Reason: the return
        statements are not positioned on a multiple of 4 spaces, if that is the
        indentation depth.

        f(x,
        function() {
        return 1;
        });
        f2(x,
        function() {
        return 2;
        });

        But:

        1. The fix is strange to read:

        f(x,
        function() {
        return 1;
        });
        f2(x,
        function() {
        return 2;
        });

        2. Specifying this indentation rule to auto-indenting editors is
        impossible or at least non-trivial.

        > 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.

        Seems to work great over here, thanks! I only had to correct the
        placement of some curly braces. But I understand that this is necessary
        for avoiding trouble with automatic semicolon insertion. Example:

        if (x == 1 &&
        y == 2)
        { // <-- better readable here, but to be avoided due to JS limitations
      • Merlin
        There s a new version of my Yahoo! Widget Tester Widget with JSLint Edition 2011-01-06 at http://tinyurl.com/5unocx . It s also been submitted as an update to
        Message 3 of 12 , Jan 8, 2011
        • 0 Attachment
          There's a new version of my Yahoo! Widget Tester Widget with JSLint Edition 2011-01-06 at http://tinyurl.com/5unocx . It's also been submitted as an update to the Yahoo! Widget Gallery.

          --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
          > 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've not yet done anything with the tree, as I doubt most users would want to see it. Perhaps a context menu item to display it would suffice.

          > 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.

          I've removed these.

          > 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.
          >

          Nothing important broke with my code, apart from having to reformat where I had

          }
          else

          on successive lines.
        • aceblchboy
          ... I m aware of two beautifiers: JSBeautifier.org and jsutility.pjoneil.net Your style looks like the style pjoneil uses.
          Message 4 of 12 , Jan 9, 2011
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, "Felix E. Klee" <felix.klee@...> wrote:
            >
            > On Sat, Jan 8, 2011 at 1:17 AM, Douglas Crockford
            > <douglas@...> wrote:
            > > at the moment, JSLint does not consider indentation
            >
            > In fact that's a very good omission. The last version would report that
            > the following code is not properly indented. Reason: the return
            > statements are not positioned on a multiple of 4 spaces, if that is the
            > indentation depth.
            >
            > f(x,
            > function() {
            > return 1;
            > });
            > f2(x,
            > function() {
            > return 2;
            > });
            >
            > But:
            >
            > 1. The fix is strange to read:
            >
            > f(x,
            > function() {
            > return 1;
            > });
            > f2(x,
            > function() {
            > return 2;
            > });
            >
            > 2. Specifying this indentation rule to auto-indenting editors is
            > impossible or at least non-trivial.
            >
            > > 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.
            >
            > Seems to work great over here, thanks! I only had to correct the
            > placement of some curly braces. But I understand that this is necessary
            > for avoiding trouble with automatic semicolon insertion. Example:
            >
            > if (x == 1 &&
            > y == 2)
            > { // <-- better readable here, but to be avoided due to JS limitations
            >

            I'm aware of two beautifiers: JSBeautifier.org and jsutility.pjoneil.net Your style looks like the style pjoneil uses.
          • Luke Page
            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
            Message 5 of 12 , 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]
            • Jordan
              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
              Message 6 of 12 , Jan 10, 2011
              • 0 Attachment
                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.
                >
              • Douglas Crockford
                ... Clearly code quality is not important to you, or you would not be demanding your right to write incompetent crap.
                Message 7 of 12 , Jan 10, 2011
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, "Jordan" <ljharb@...> wrote:
                  > 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?


                  Clearly code quality is not important to you, or you would not be demanding your right to write incompetent crap.
                • Jordan
                  I didn t write this code, and would certainly prefer a better solution if you have one in mind. In addition I did not demand anything, I simply requested a
                  Message 8 of 12 , Jan 11, 2011
                  • 0 Attachment
                    I didn't write this code, and would certainly prefer a better solution if you have one in mind. In addition I did not demand anything, I simply requested a feature you blindly removed, on a thread where you asked for feedback.

                    I'm merely requesting the option to bend on code quality where necessary for production use cases.

                    If JSLint (which via its configuration options has always done an excellent job of walking the line between an ideological code quality tool, and a production code validator) is now ignoring practical use cases, then I request that you remove all of the configuration options, and remove all pretense of attempting to make JSLint useful for production code.

                    --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                    >
                    > --- In jslint_com@yahoogroups.com, "Jordan" <ljharb@> wrote:
                    > > 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?
                    >
                    >
                    > Clearly code quality is not important to you, or you would not be demanding your right to write incompetent crap.
                    >
                  • Felix E. Klee
                    ... Put the code into a separate file that you don t run through JSLint.
                    Message 9 of 12 , Jan 11, 2011
                    • 0 Attachment
                      On Tue, Jan 11, 2011 at 11:36 PM, Jordan <ljharb@...> wrote:
                      > I didn't write this code, and would certainly prefer a better solution

                      Put the code into a separate file that you don't run through JSLint.
                    • Jordan
                      That is indeed a good suggestion, but that doesn t prevent the file concatenation problem, nor does it invalidate my request for all configuration options to
                      Message 10 of 12 , Jan 11, 2011
                      • 0 Attachment
                        That is indeed a good suggestion, but that doesn't prevent the file concatenation problem, nor does it invalidate my request for all configuration options to be removed if the sole concern of JSLint is code quality instead of production code validation.

                        --- In jslint_com@yahoogroups.com, "Felix E. Klee" <felix.klee@...> wrote:
                        >
                        > On Tue, Jan 11, 2011 at 11:36 PM, Jordan <ljharb@...> wrote:
                        > > I didn't write this code, and would certainly prefer a better solution
                        >
                        > Put the code into a separate file that you don't run through JSLint.
                        >
                      • Felix E. Klee
                        ... What do you mean by that?
                        Message 11 of 12 , Jan 11, 2011
                        • 0 Attachment
                          On Wed, Jan 12, 2011 at 12:27 AM, Jordan <ljharb@...> wrote:
                          > the file concatenation problem,

                          What do you mean by that?
                        • abyssoft@ymail.com
                          I believe that Mr. Crockford would say something to this effect in response. Your sadly pathetic bleatings are harshing my mellow. - Douglas Crockford as he
                          Message 12 of 12 , Jan 14, 2011
                          • 0 Attachment
                            I believe that Mr. Crockford would say something to this effect in response.

                            "Your sadly pathetic bleatings are harshing my mellow." - Douglas Crockford

                            as he did to me on a similar issue.

                            My advice, do what I ultimately did after my bruised emotions calloused over, rewrite the offending code. Yes, it takes away valuable resource time from a potential deadlines, that could affect your employment. Yes, you may have your feelings hurt as a result of a previous coder's coding badly. Yes in the long run it makes you a better coder, as you'll be able to more quickly fix crap code. Yes, you have a choice to make, either do as I did and toughen up the skin a bit and make the code compatible and validate (which includes fixing other people's crap) or; don't worry about being a good JS developer and write incompetent code, and don't bother trying to use JSLint.
                          Your message has been successfully submitted and would be delivered to recipients shortly.