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

Re: [jslint] New Edition

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.