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

Re: Array construction bug

Expand Messages
  • Alexandre Morgaut
    Yes there is a workaround, one that still respect JSLint guidelines You can fix the length without the array constructor, even with a dynamic value Just do:
    Message 1 of 21 , Aug 31, 2012
    • 0 Attachment
      Yes there is a workaround, one that still respect JSLint guidelines

      You can fix the length without the array constructor, even with a dynamic value

      Just do:

      var len = 50;
      var arr = [];
      arr.length = len;

      --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
      >
      > If I need to create an array with a specified length, and the length
      > is a literal, JSLint is happy enough with this:
      >
      > var arr = new Array(50);
      >
      > If, however, the value comes from a variable:
      >
      > var len = 50,
      > arr = new Array(len);
      >
      > JSLint complains with an unusable "solution", despite the value being a Number:
      >
      > Use the array literal notation [].
      >
      > Of course, if I use array literal notation, I don't get the semantics I want.
      >
      > Seems like a bug to me. Is there a workaround?
      >
    • Joe Hansche
      According to MDN that is not what actually happens: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/length You can only
      Message 2 of 21 , Aug 31, 2012
      • 0 Attachment
        According to MDN that is not what actually happens:
        https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/length

        You can only truncate an array's length. Artificially increasing an array's
        "length" still serves no purpose if you don't initialize what's *in* it.
        On Aug 31, 2012 3:59 AM, "Alexandre Morgaut" <morgaut@...> wrote:

        > **
        >
        >
        > Yes there is a workaround, one that still respect JSLint guidelines
        >
        > You can fix the length without the array constructor, even with a dynamic
        > value
        >
        > Just do:
        >
        > var len = 50;
        > var arr = [];
        > arr.length = len;
        >
        > --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
        > >
        > > If I need to create an array with a specified length, and the length
        > > is a literal, JSLint is happy enough with this:
        > >
        > > var arr = new Array(50);
        > >
        > > If, however, the value comes from a variable:
        > >
        > > var len = 50,
        > > arr = new Array(len);
        > >
        > > JSLint complains with an unusable "solution", despite the value being a
        > Number:
        > >
        > > Use the array literal notation [].
        > >
        > > Of course, if I use array literal notation, I don't get the semantics I
        > want.
        > >
        > > Seems like a bug to me. Is there a workaround?
        > >
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Arild Haugstad
        When experimenting with the developer console in Chrome and FireBug in FireFox, the effects of the two methods appear to be *exactly* the same. While setting
        Message 3 of 21 , Aug 31, 2012
        • 0 Attachment
          When experimenting with the developer console in Chrome and FireBug in
          FireFox, the effects of the two methods appear to be *exactly* the
          same.
          While setting the "length" property of an Array is not very useful;
          constructing the array with a numeric arguments gives the same result;
          i.e.
          var myArray = new Array(50);
          results in an array with no actual elements and "length" set to 50, while
          var myArray = [];
          myArray.length = 50;
          also results in an array with no actual elements and "length" set to 50...

          Do other browser actually behave differently in a way which makes the
          first variant more useful than the last?



          On 31 August 2012 10:22, Joe Hansche <madcoder@...> wrote:
          > According to MDN that is not what actually happens:
          > https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/length
          >
          > You can only truncate an array's length. Artificially increasing an array's
          > "length" still serves no purpose if you don't initialize what's *in* it.
          > On Aug 31, 2012 3:59 AM, "Alexandre Morgaut" <morgaut@...> wrote:
          >
          >> **
          >>
          >>
          >> Yes there is a workaround, one that still respect JSLint guidelines
          >>
          >> You can fix the length without the array constructor, even with a dynamic
          >> value
          >>
          >> Just do:
          >>
          >> var len = 50;
          >> var arr = [];
          >> arr.length = len;
          >>
          >> --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
          >> >
          >> > If I need to create an array with a specified length, and the length
          >> > is a literal, JSLint is happy enough with this:
          >> >
          >> > var arr = new Array(50);
          >> >
          >> > If, however, the value comes from a variable:
          >> >
          >> > var len = 50,
          >> > arr = new Array(len);
          >> >
          >> > JSLint complains with an unusable "solution", despite the value being a
          >> Number:
          >> >
          >> > Use the array literal notation [].
          >> >
          >> > Of course, if I use array literal notation, I don't get the semantics I
          >> want.
          >> >
          >> > Seems like a bug to me. Is there a workaround?
          >> >
          >>
          >>
          >>
          >
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
        • Alexandre Morgaut
          ... The MDN documentation is unfortunately not very clear on this page. It says that the array still contain only 2 elements . It s true, as when you do new
          Message 4 of 21 , Aug 31, 2012
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, Joe Hansche <madcoder@...> wrote:
            >
            > According to MDN that is not what actually happens:
            > https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/length
            >
            > You can only truncate an array's length. Artificially increasing an array's
            > "length" still serves no purpose if you don't initialize what's *in* it.

            The MDN documentation is unfortunately not very clear on this page.
            It says that "the array still contain only 2 elements".

            It's true, as when you do "new Array(50)" the array will be physically empty, only its length property will be impacted.

            Setting a specific length is still not useless. It has an impact on many of its methods like pop(), push(), shift(), unshift(), splice(), concat(), ...

            It is often used also to fill a string

            var arr, str;
            arr = [];
            arr.length = 51;
            str = arr.join('0'); // generate a string with 50 "0"

            But for performance concerns it won't always help with methods like map(callback)

            "callback is invoked only for indexes of the array which have assigned values; it is not invoked for indexes which have been deleted or which have never been assigned values."

            So if map is called on an array with length of 50 and with only 3 filled elements, the resulting array will have the same length but the callback will be called only 3 times and you won't be able to fill the other elements of this array via map()
          • douglascrockford
            ... new Array is deeply confusing to people coming to JavaScript from other languages because JavaScript s arrays do not work as expected. Much of that
            Message 5 of 21 , Aug 31, 2012
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
              >
              > If I need to create an array with a specified length, and the length
              > is a literal, JSLint is happy enough with this:
              >
              > var arr = new Array(50);
              >
              > If, however, the value comes from a variable:
              >
              > var len = 50,
              > arr = new Array(len);
              >
              > JSLint complains with an unusable "solution", despite the value being a Number:
              >
              > Use the array literal notation [].
              >
              > Of course, if I use array literal notation, I don't get the semantics I want.
              >
              > Seems like a bug to me. Is there a workaround?

              new Array is deeply confusing to people coming to JavaScript from other languages because JavaScript's arrays do not work as expected. Much of that confusion can be avoided by always using array literals.

              There is a workaround, setting .length, but now that you have raised the issue, perhaps I should give a warning on that as well.

              This started with your hypothetical "if I need to". I have not yet seen a case that supports your hypothetical.
            • Martin Cooper
              ... If I want to create, say, a separator line of len dashes, I can do that really cleanly and easily with: var separator = Array(len).join( - ); If there s
              Message 6 of 21 , Aug 31, 2012
              • 0 Attachment
                On Fri, Aug 31, 2012 at 5:34 AM, douglascrockford <douglas@...> wrote:
                > --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
                >>
                >> If I need to create an array with a specified length, and the length
                >> is a literal, JSLint is happy enough with this:
                >>
                >> var arr = new Array(50);
                >>
                >> If, however, the value comes from a variable:
                >>
                >> var len = 50,
                >> arr = new Array(len);
                >>
                >> JSLint complains with an unusable "solution", despite the value being a Number:
                >>
                >> Use the array literal notation [].
                >>
                >> Of course, if I use array literal notation, I don't get the semantics I want.
                >>
                >> Seems like a bug to me. Is there a workaround?
                >
                > new Array is deeply confusing to people coming to JavaScript from other languages because JavaScript's arrays do not work as expected. Much of that confusion can be avoided by always using array literals.
                >
                > There is a workaround, setting .length, but now that you have raised the issue, perhaps I should give a warning on that as well.
                >
                > This started with your hypothetical "if I need to". I have not yet seen a case that supports your hypothetical.

                If I want to create, say, a separator line of 'len' dashes, I can do
                that really cleanly and easily with:

                var separator = Array(len).join('-');

                If there's a one-liner that is just as simple, clean, and obvious as
                that, I'll be happy to use it. But please don't tell me I have to dumb
                down my code and use a multi-line function to do something that works
                perfectly well - until I try to get it past JSLint.

                --
                Martin Cooper


                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
              • Luke Page
                ... Wouldn t it be clearer and more maintainable to create a function for it anyway? var seperator = repeatString( - , len); it doesn t look as clever to use
                Message 7 of 21 , Aug 31, 2012
                • 0 Attachment
                  > If I want to create, say, a separator line of 'len' dashes, I can do
                  > that really cleanly and easily with:
                  >
                  > var separator = Array(len).join('-');
                  >

                  Wouldn't it be clearer and more maintainable to create a function for it
                  anyway?

                  var seperator = repeatString('-', len);

                  it doesn't look as "clever" to use a for loop to concatenate, but is there
                  a noticeable performance loss? Is it easier to read and understand?


                  > If there's a one-liner that is just as simple, clean, and obvious as
                  > that, I'll be happy to use it. But please don't tell me I have to dumb
                  > down my code and use a multi-line function to do something that works
                  > perfectly well - until I try to get it past JSLint.
                  >
                  > --
                  > Martin Cooper
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Alexandre Morgaut
                  ... I think that it s more maintainable and more secure to use a dedicated function One going to the code using the Array constructor might expect that the
                  Message 8 of 21 , Aug 31, 2012
                  • 0 Attachment
                    --- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
                    >
                    > > If I want to create, say, a separator line of 'len' dashes, I can do
                    > > that really cleanly and easily with:
                    > >
                    > > var separator = Array(len).join('-');
                    > >
                    >
                    > Wouldn't it be clearer and more maintainable to create a function for it
                    > anyway?
                    >
                    > var seperator = repeatString('-', len);
                    >
                    > it doesn't look as "clever" to use a for loop to concatenate, but is there
                    > a noticeable performance loss? Is it easier to read and understand?

                    I think that it's more maintainable and more secure to use a dedicated function
                    One going to the code using the Array constructor might expect that the numebr of characters in the string will be len while it will be (len -1). And even if he take care of that it will mean that most of the time the one line will be:

                    var str = Array(nbChars + 1).join(char);

                    It will then become ever less obvious to understand what this code is for compared to

                    var str = repeatString(char, nbChars);

                    One of the goals of JSLint is to make your code more maintainable by anyone (even you some some few years...)
                  • Martin Cooper
                    ... Right. So I personally find that taking advantage of what the language has to offer helps me do that. If I have to write a function, document it, and write
                    Message 9 of 21 , Aug 31, 2012
                    • 0 Attachment
                      On Fri, Aug 31, 2012 at 7:41 AM, Alexandre Morgaut <morgaut@...> wrote:
                      > --- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
                      >>
                      >> > If I want to create, say, a separator line of 'len' dashes, I can do
                      >> > that really cleanly and easily with:
                      >> >
                      >> > var separator = Array(len).join('-');
                      >> >
                      >>
                      >> Wouldn't it be clearer and more maintainable to create a function for it
                      >> anyway?
                      >>
                      >> var seperator = repeatString('-', len);
                      >>
                      >> it doesn't look as "clever" to use a for loop to concatenate, but is there
                      >> a noticeable performance loss? Is it easier to read and understand?
                      >
                      > I think that it's more maintainable and more secure to use a dedicated function
                      > One going to the code using the Array constructor might expect that the numebr of characters in the string will be len while it will be (len -1). And even if he take care of that it will mean that most of the time the one line will be:
                      >
                      > var str = Array(nbChars + 1).join(char);
                      >
                      > It will then become ever less obvious to understand what this code is for compared to
                      >
                      > var str = repeatString(char, nbChars);
                      >
                      > One of the goals of JSLint is to make your code more maintainable by anyone (even you some some few years...)

                      Right. So I personally find that taking advantage of what the language
                      has to offer helps me do that. If I have to write a function, document
                      it, and write unit tests for it, have I really improved the ability to
                      maintain my code, over using the language the way it was designed?

                      In my case, I'm writing code for professional JavaScript developers,
                      not noobs. I want JSLint to help me find bugs, not tell me I have to
                      dumb down my code for people who don't understand the language. Having
                      a warning that I can turn off if I want to use a language feature is
                      fine; providing no way to get past JSLint while using a perfectly
                      legal language feature is not.

                      --
                      Martin Cooper


                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                    • Tom Worster
                      ... if a separator line is unlikely to be of variable length (which is probably so): var separator = ---------------------------------------- ; looks good to
                      Message 10 of 21 , Aug 31, 2012
                      • 0 Attachment
                        On 8/31/12 10:07 AM, "Martin Cooper" <mfncooper@...> wrote:

                        >
                        >If I want to create, say, a separator line of 'len' dashes, I can do
                        >that really cleanly and easily with:
                        >
                        >var separator = Array(len).join('-');

                        if a separator line is unlikely to be of variable length (which is
                        probably so):

                        var separator = '----------------------------------------';


                        looks good to me.

                        a more reasonable example of something like this is string padding.
                        http://phpjs.org/functions/date:380 has a great example at line 67

                        getting rid of the constructor as JSLint proposes is a good idea:

                        _pad = function (n, c) {
                        n = n.toString();
                        while (n.length < c) {
                        n = '0' + n;
                        }
                        return n;
                        },

                        trying to do things as one-liners is often a sign of trying to be
                        clever, which is something JSLint tries to discourage.


                        not a bug, in my view.
                      • IcedNet Development Team
                        You may not code for noobs , but you will have new hires, and you will document that one-liner or have to explain it, even to professionals... Knowing how to
                        Message 11 of 21 , Aug 31, 2012
                        • 0 Attachment
                          You may not code for "noobs", but you will have new hires, and you will document that one-liner or have to explain it, even to professionals...
                          Knowing how to code in js does not necessarily mean that everyone has read "The Good Parts" or any of the exhaustive tomes that actually mention the misbehavior of core javascript...
                          Clever code is not clever, and that line could mean anything, let alone relying on the moving target that is js...

                          I see no bug here.

                          .02 worth

                          Peace,
                          Dan


                          On 2012/08 /31, at 10:07 AM, Martin Cooper wrote:

                          >
                          >
                          > If I want to create, say, a separator line of 'len' dashes, I can do
                          > that really cleanly and easily with:
                          >
                          > var separator = Array(len).join('-');
                          >
                          > If there's a one-liner that is just as simple, clean, and obvious as
                          > that, I'll be happy to use it. But please don't tell me I have to dumb
                          > down my code and use a multi-line function to do something that works
                          > perfectly well - until I try to get it past JSLint.
                          >
                          > --
                          > Martin Cooper
                          >
                          > > ------------------------------------
                          > >
                          > > Yahoo! Groups Links
                          > >
                          > >
                          >
                          >



                          [Non-text portions of this message have been removed]
                        • Martin Cooper
                          On Fri, Aug 31, 2012 at 8:09 AM, IcedNet Development Team ... It s not supposed to be clever . I am only trying to use a feature that exists in the language.
                          Message 12 of 21 , Aug 31, 2012
                          • 0 Attachment
                            On Fri, Aug 31, 2012 at 8:09 AM, IcedNet Development Team
                            <dev@...> wrote:
                            > You may not code for "noobs", but you will have new hires, and you will document that one-liner or have to explain it, even to professionals...
                            > Knowing how to code in js does not necessarily mean that everyone has read "The Good Parts" or any of the exhaustive tomes that actually mention the misbehavior of core javascript...
                            > Clever code is not clever, and that line could mean anything, let alone relying on the moving target that is js...

                            It's not supposed to be "clever". I am only trying to use a feature
                            that exists in the language. If the feature wasn't intended to be
                            used, it wouldn't be there. To say that that tiny amount of code
                            "could mean anything" is absurd.

                            > I see no bug here.

                            Setting aside whether people agree or disagree with my particular use
                            case, the fact is that JSLint provides *no* way for me to take
                            advantage of this specific feature of the JavaScript language. None.
                            There is no "off" switch for this. That is a bug.

                            --
                            Martin Cooper


                            > .02 worth
                            >
                            > Peace,
                            > Dan
                            >
                            >
                            > On 2012/08 /31, at 10:07 AM, Martin Cooper wrote:
                            >
                            >>
                            >>
                            >> If I want to create, say, a separator line of 'len' dashes, I can do
                            >> that really cleanly and easily with:
                            >>
                            >> var separator = Array(len).join('-');
                            >>
                            >> If there's a one-liner that is just as simple, clean, and obvious as
                            >> that, I'll be happy to use it. But please don't tell me I have to dumb
                            >> down my code and use a multi-line function to do something that works
                            >> perfectly well - until I try to get it past JSLint.
                            >>
                            >> --
                            >> Martin Cooper
                            >>
                            >> > ------------------------------------
                            >> >
                            >> > Yahoo! Groups Links
                            >> >
                            >> >
                            >>
                            >>
                            >
                            >
                            >
                            > [Non-text portions of this message have been removed]
                            >
                            >
                            >
                            > ------------------------------------
                            >
                            > Yahoo! Groups Links
                            >
                            >
                            >
                          • IcedNet Development Team
                            Please, you assume much Is it creating a new array of length len and joining it to the string literal - ? -- and JSLint is supposed to make code clearer...
                            Message 13 of 21 , Aug 31, 2012
                            • 0 Attachment
                              Please, you assume much
                              Is it creating a new array of length 'len' and joining it to the string literal '-' ?

                              -- and JSLint is supposed to make code clearer...

                              Not arguing your desire, just restating what Douglas has said time (and time again)...

                              Good luck.

                              Peace,
                              Dan

                              On 2012/08 /31, at 12:30 PM, Martin Cooper wrote:

                              > On Fri, Aug 31, 2012 at 8:09 AM, IcedNet Development Team
                              > <dev@...> wrote:
                              > > You may not code for "noobs", but you will have new hires, and you will document that one-liner or have to explain it, even to professionals...
                              > > Knowing how to code in js does not necessarily mean that everyone has read "The Good Parts" or any of the exhaustive tomes that actually mention the misbehavior of core javascript...
                              > > Clever code is not clever, and that line could mean anything, let alone relying on the moving target that is js...
                              >
                              > It's not supposed to be "clever". I am only trying to use a feature
                              > that exists in the language. If the feature wasn't intended to be
                              > used, it wouldn't be there. To say that that tiny amount of code
                              > "could mean anything" is absurd.
                              >
                              > > I see no bug here.
                              >
                              > Setting aside whether people agree or disagree with my particular use
                              > case, the fact is that JSLint provides *no* way for me to take
                              > advantage of this specific feature of the JavaScript language. None.
                              > There is no "off" switch for this. That is a bug.
                              >
                              > --
                              > Martin Cooper
                              >
                              > > .02 worth
                              > >
                              > > Peace,
                              > > Dan
                              > >
                              > >
                              > > On 2012/08 /31, at 10:07 AM, Martin Cooper wrote:
                              > >
                              > >>
                              > >>
                              > >> If I want to create, say, a separator line of 'len' dashes, I can do
                              > >> that really cleanly and easily with:
                              > >>
                              > >> var separator = Array(len).join('-');
                              > >>
                              > >> If there's a one-liner that is just as simple, clean, and obvious as
                              > >> that, I'll be happy to use it. But please don't tell me I have to dumb
                              > >> down my code and use a multi-line function to do something that works
                              > >> perfectly well - until I try to get it past JSLint.
                              > >>
                              > >> --
                              > >> Martin Cooper
                              > >>
                              > >> > ------------------------------------
                              > >> >
                              > >> > Yahoo! Groups Links
                              > >> >
                              > >> >
                              > >>
                              > >>
                              > >
                              > >
                              > >
                              > > [Non-text portions of this message have been removed]
                              > >
                              > >
                              > >
                              > > ------------------------------------
                              > >
                              > > Yahoo! Groups Links
                              > >
                              > >
                              > >
                              >



                              [Non-text portions of this message have been removed]
                            • John Hawkinson
                              One of the problems I have with this discussion is that the cost of having to go read this repeatString() function, however it is implemented, is significant.
                              Message 14 of 21 , Aug 31, 2012
                              • 0 Attachment
                                One of the problems I have with this discussion is that
                                the cost of having to go read this repeatString() function,
                                however it is implemented, is significant. But some analysis
                                appears to ignore that.

                                The oneliner proposed is fairly clear to me.
                                More so than the for loop variants.

                                But even if they were more clear, I do not think that would justify
                                the programmer cost of having another function to review, test, and
                                consider.

                                But either way, these are reasonable judgements and it seems like yet
                                another reminder that JSLint is not a JS code quality tool, as much as
                                it is a style enforcement tool, and for only one person's style in
                                particular.

                                And it is the nature of style that it varies wildly and it is rare
                                indeed for two programmers to see eye-to-eye on all style points.

                                It saddens me that JSLint, which could be an awesome tool,
                                instead is just about fights over style. I wish we could rise
                                above this, but I do not see a path forward.

                                --jhawk@...
                                John Hawkinson
                              • Tom Worster
                                i just think JSLint isn t for everyone. i had been using it with greater or lesser enthusiasm for years until, after watching the video of douglas talk at
                                Message 15 of 21 , Sep 1, 2012
                                • 0 Attachment
                                  i just think JSLint isn't for everyone.

                                  i had been using it with greater or lesser enthusiasm for years until,
                                  after watching the video of douglas' talk at txjs11 several times, i had a
                                  blinding conversion. finally i saw that it doesn't matter what i think
                                  about code style. the only thing that matters is reducing the chance of
                                  bugs now and in the future while assuming that my code is going to be
                                  inherited by marginally competent programmers(*).

                                  before this conversion, JSLint would sometimes annoy me with its nagging.
                                  the annoyance would manifest something like "but i know what i'm doing" or
                                  "but i don't like that" or "my version is better". now, whenever that
                                  feeling comes upon me i tell myself (sometimes out loud): "it doesn't
                                  matter what you prefer, tom, not even a little bit." and once i calm down
                                  i can usually see the wisdom of JSLint's suggestion.

                                  code is not design and programming is not the act of designing.
                                  programming is a dreadful business. i welcome anything that can improve
                                  the chance that the program will be and will remain correct.

                                  but obviously many programmers don't share my view. and JSLint isn't for
                                  everyone.

                                  and, btw, i liked one part of douglas' talk so much i transcribed it:
                                  http://thefsb.wordpress.com/2012/07/10/code-quality/

                                  (*) and when i'm really honest with myself i have to count myself among
                                  them.
                                • benquarmby
                                  Hey Tom, That TXJS11 talk was great wasn t it! http://vimeo.com/25606006 If you can switch off the emotional side of your brain, the logic is very hard to
                                  Message 16 of 21 , Sep 2, 2012
                                  • 0 Attachment
                                    Hey Tom,

                                    That TXJS11 talk was great wasn't it!
                                    http://vimeo.com/25606006

                                    If you can switch off the emotional side of your brain, the logic is very hard to refute. There are whole classes of errors you will never see when using JSLint. It improves the odds of success, and in terms of QA and support costs, those odds are measured in dollars.

                                    As far as style goes, I also recommend Jeff Atwood's blog post "Death to the Space Infidels":
                                    http://www.codinghorror.com/blog/2009/04/death-to-the-space-infidels.html

                                    I could go on about how debilitating opinionated format wars and code style "creative differences" can be, both to a team and the software they produce. Instead, I'll just encourage everyone: If you work as part of a team of any size other than one, rely on this cold, heartless tool to get your JavaScript code-base consistent. It can take all the gnashing of teeth and chest pounding your team can throw at it.

                                    --- In jslint_com@yahoogroups.com, Tom Worster <fsb@...> wrote:
                                    >
                                    > i just think JSLint isn't for everyone.
                                    >
                                    > i had been using it with greater or lesser enthusiasm for years until,
                                    > after watching the video of douglas' talk at txjs11 several times, i had a
                                    > blinding conversion. finally i saw that it doesn't matter what i think
                                    > about code style. the only thing that matters is reducing the chance of
                                    > bugs now and in the future while assuming that my code is going to be
                                    > inherited by marginally competent programmers(*).
                                    >
                                    > before this conversion, JSLint would sometimes annoy me with its nagging.
                                    > the annoyance would manifest something like "but i know what i'm doing" or
                                    > "but i don't like that" or "my version is better". now, whenever that
                                    > feeling comes upon me i tell myself (sometimes out loud): "it doesn't
                                    > matter what you prefer, tom, not even a little bit." and once i calm down
                                    > i can usually see the wisdom of JSLint's suggestion.
                                    >
                                    > code is not design and programming is not the act of designing.
                                    > programming is a dreadful business. i welcome anything that can improve
                                    > the chance that the program will be and will remain correct.
                                    >
                                    > but obviously many programmers don't share my view. and JSLint isn't for
                                    > everyone.
                                    >
                                    > and, btw, i liked one part of douglas' talk so much i transcribed it:
                                    > http://thefsb.wordpress.com/2012/07/10/code-quality/
                                    >
                                    > (*) and when i'm really honest with myself i have to count myself among
                                    > them.
                                    >
                                  • Joe Hansche
                                    ... I agree with this. I really don t disagree with Crawford, or JSLint... but on SOME things I do. I use it a lot, because you re right: it does find bugs
                                    Message 17 of 21 , Oct 2, 2012
                                    • 0 Attachment
                                      On Sun, Sep 2, 2012 at 6:31 PM, benquarmby <ben.quarmby@...>wrote:

                                      > **
                                      >
                                      >
                                      > Hey Tom,
                                      >
                                      > That TXJS11 talk was great wasn't it!
                                      > http://vimeo.com/25606006
                                      >
                                      > If you can switch off the emotional side of your brain, the logic is very
                                      > hard to refute. There are whole classes of errors you will never see when
                                      > using JSLint. It improves the odds of success, and in terms of QA and
                                      > support costs, those odds are measured in dollars.
                                      >
                                      > As far as style goes, I also recommend Jeff Atwood's blog post "Death to
                                      > the Space Infidels":
                                      > http://www.codinghorror.com/blog/2009/04/death-to-the-space-infidels.html
                                      >
                                      > I could go on about how debilitating opinionated format wars and code
                                      > style "creative differences" can be, both to a team and the software they
                                      > produce. Instead, I'll just encourage everyone: If you work as part of a
                                      > team of any size other than one, rely on this cold, heartless tool to get
                                      > your JavaScript code-base consistent. It can take all the gnashing of teeth
                                      > and chest pounding your team can throw at it.
                                      >
                                      I agree with this. I really don't disagree with Crawford, or JSLint...
                                      but on SOME things I do. I use it a lot, because you're right: it does
                                      find bugs that other people might mistake or miss. I do all I can to avoid
                                      the JSLint errors that come up in my own files. I will rewrite stuff, move
                                      stuff around, etc, to reduce the number of JSLint errors I see. What sucks
                                      is that not all of my coworkers use JSLint. So when I do (in other
                                      people's files), most of the mistakes are not mine. And being in a
                                      corporate world, I really don't have the luxury of just changing all their
                                      shit around, unfortunately.

                                      And unfortunately, some of the complaints are about things that are so
                                      trivial, I can't really justify (passing a code review) changing everything
                                      about a JS file just because JSLint says it's bad. I might agree with the
                                      a lot of it, but if I want to get my code to production, trust me, I'm not
                                      going to follow JSLint to fix all the other issues in the file (which I
                                      didn't write).

                                      I use JSLint on my own (new) files, because I know that it will end up in
                                      better code. Code that I can manage better, in case bugs are found; and
                                      in case someone else has to touch it, hopefully they are faced with far
                                      fewer issues to deal with.

                                      That said, I don't agree with the *attitude* that Crawford takes on the
                                      *programmers*. I work with a lot of very talented individuals. But the
                                      general consensus is, if you don't write in HIS style, you are a BAD
                                      programmer. I have more colorful words to describe my distaste in that,
                                      but let's just leave it at "I am not moved" by his distrust of the entire
                                      development community. I have my style, he has his. My style to date has
                                      not left me in a bad state, and I still try to follow his "suggestions," as
                                      far as JSLint is concerned.

                                      But for other developers out there, you have to weigh the cost of following
                                      Crawford, vs finding your own style (and please do be sure that it is both
                                      safe and sane -- his rules do have purpose, and you must make sure that
                                      your style takes into account those reasons). Just don't get sucked into
                                      following JSLint only because the tool says you should. If you understand
                                      the reason behind the warning, and you know why you did something some way
                                      that the linter tells you you shouldn't... It's okay. It's okay to
                                      violate JSLint. It's okay to violate Crawford's style.

                                      It's only a style, by the way. It's not a bad style, by any means. It's a
                                      great way to teach uninformed programmers that what they are trying to do
                                      is far and away a bad thing to do -- and the tool will tell you that.

                                      For an experienced programmer, specifically one who knows what the rules
                                      are intended for, it's a little overkill. But then it's your job to decide
                                      if the rules are worth following or not. If you can determine that,
                                      knowing full well what the rule is designed to suggest *against*, yet you
                                      have a reason for it anyway, ... then just ignore that rule. You don't
                                      have to worry about hurting Crawford's feelings for doing so (he'll *never*
                                      feel bad about hurting your feelings).


                                      --- In jslint_com@yahoogroups.com, Tom Worster <fsb@...> wrote:
                                      > >
                                      > > i just think JSLint isn't for everyone.
                                      > >
                                      > > i had been using it with greater or lesser enthusiasm for years until,
                                      > > after watching the video of douglas' talk at txjs11 several times, i had
                                      > a
                                      > > blinding conversion. finally i saw that it doesn't matter what i think
                                      > > about code style. the only thing that matters is reducing the chance of
                                      > > bugs now and in the future while assuming that my code is going to be
                                      > > inherited by marginally competent programmers(*).
                                      > >
                                      > > before this conversion, JSLint would sometimes annoy me with its nagging.
                                      > > the annoyance would manifest something like "but i know what i'm doing"
                                      > or
                                      > > "but i don't like that" or "my version is better". now, whenever that
                                      > > feeling comes upon me i tell myself (sometimes out loud): "it doesn't
                                      > > matter what you prefer, tom, not even a little bit." and once i calm down
                                      > > i can usually see the wisdom of JSLint's suggestion.
                                      > >
                                      > > code is not design and programming is not the act of designing.
                                      > > programming is a dreadful business. i welcome anything that can improve
                                      > > the chance that the program will be and will remain correct.
                                      > >
                                      > > but obviously many programmers don't share my view. and JSLint isn't for
                                      > > everyone.
                                      > >
                                      > > and, btw, i liked one part of douglas' talk so much i transcribed it:
                                      > > http://thefsb.wordpress.com/2012/07/10/code-quality/
                                      > >
                                      > > (*) and when i'm really honest with myself i have to count myself among
                                      > > them.
                                      > >
                                      >
                                      >
                                      >


                                      [Non-text portions of this message have been removed]
                                    Your message has been successfully submitted and would be delivered to recipients shortly.