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

Re: [jslint] Array construction bug

Expand Messages
  • 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 1 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 2 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 3 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.