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

Re: New Edition

Expand Messages
  • aceblchboy
    ... I m aware of two beautifiers: JSBeautifier.org and jsutility.pjoneil.net Your style looks like the style pjoneil uses.
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.