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

Re: [jslint] JSLint options saved as a cookie.

Expand Messages
  • pauanyu
    ... Why would I want to add this to top of every one of my dozens and dozens of JavaScript, CSS, and HTML files: /*jslint white: true, onevar: true, browser:
    Message 1 of 11 , Aug 20 6:06 PM
    • 0 Attachment
      --- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
      >
      > IMHO, even nicer and more useful than using the cookie, is simply specifying
      > the jslintoptions at the top of your JS file!
      >
      > That way you can customize the setting on a per file basis if needed too!
      >

      Why would I want to add this to top of every one of my dozens and dozens of JavaScript, CSS, and HTML files:

      /*jslint white: true, onevar: true, browser: true, undef: true, nomen: true, eqeqeq: true, plusplus: true, bitwise: true, regexp: true, strict: true, newcap: true, immed: true */

      ?

      As for specifying options per-file.. I have absolutely no need for that. I always write my code as cleanly as possible.
    • Arthur Blake
      Just expressing my humble opinion... another few good reasons: 1. your code can be used in other JSLint environments (instead of just the web front end) and be
      Message 2 of 11 , Aug 21 7:22 AM
      • 0 Attachment
        Just expressing my humble opinion... another few good reasons:
        1. your code can be used in other JSLint environments (instead of just the
        web front end) and be validated consistently. For example, build tools,
        like jslint4java.
        2. If you have one or two modules that just have to use eval, you can turn
        on the evil flag (or any other flag), yet turn it off for all the other
        files. That way you don't have to remember to manually change the setting.
        3. Even if it's dozens and dozens of files, you can gradually add the header
        to each file as you touch them, that's what I'm doing with my hundreds of JS
        files.

        On Thu, Aug 20, 2009 at 9:06 PM, pauanyu <pcxunlimited@...> wrote:

        >
        >
        > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Arthur
        > Blake <arthur.blake@...> wrote:
        > >
        > > IMHO, even nicer and more useful than using the cookie, is simply
        > specifying
        > > the jslintoptions at the top of your JS file!
        > >
        > > That way you can customize the setting on a per file basis if needed too!
        > >
        >
        > Why would I want to add this to top of every one of my dozens and dozens of
        > JavaScript, CSS, and HTML files:
        >
        > /*jslint white: true, onevar: true, browser: true, undef: true, nomen:
        > true, eqeqeq: true, plusplus: true, bitwise: true, regexp: true, strict:
        > true, newcap: true, immed: true */
        >
        > ?
        >
        > As for specifying options per-file.. I have absolutely no need for that. I
        > always write my code as cleanly as possible.
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Arthur Blake
        Oh, and one other good reason: The comment serves as a reminder that the file should really be checked via jslint whenever it is modified (getting other
        Message 3 of 11 , Aug 21 7:24 AM
        • 0 Attachment
          Oh, and one other good reason: The comment serves as a reminder that the
          file should really be checked via jslint whenever it is modified (getting
          other developers that work on the same code base to validate their code is
          sometimes like pulling teeth.)

          On Fri, Aug 21, 2009 at 10:22 AM, Arthur Blake <arthur.blake@...>wrote:

          > Just expressing my humble opinion... another few good reasons:
          > 1. your code can be used in other JSLint environments (instead of just the
          > web front end) and be validated consistently. For example, build tools,
          > like jslint4java.
          > 2. If you have one or two modules that just have to use eval, you can turn
          > on the evil flag (or any other flag), yet turn it off for all the other
          > files. That way you don't have to remember to manually change the setting.
          > 3. Even if it's dozens and dozens of files, you can gradually add the
          > header to each file as you touch them, that's what I'm doing with my
          > hundreds of JS files.
          >
          > On Thu, Aug 20, 2009 at 9:06 PM, pauanyu <pcxunlimited@...> wrote:
          >
          >>
          >>
          >> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Arthur
          >> Blake <arthur.blake@...> wrote:
          >> >
          >> > IMHO, even nicer and more useful than using the cookie, is simply
          >> specifying
          >> > the jslintoptions at the top of your JS file!
          >> >
          >> > That way you can customize the setting on a per file basis if needed
          >> too!
          >> >
          >>
          >> Why would I want to add this to top of every one of my dozens and dozens
          >> of JavaScript, CSS, and HTML files:
          >>
          >> /*jslint white: true, onevar: true, browser: true, undef: true, nomen:
          >> true, eqeqeq: true, plusplus: true, bitwise: true, regexp: true, strict:
          >> true, newcap: true, immed: true */
          >>
          >> ?
          >>
          >> As for specifying options per-file.. I have absolutely no need for that. I
          >> always write my code as cleanly as possible.
          >>
          >>
          >>
          >
          >


          [Non-text portions of this message have been removed]
        • Dominic Mitchell
          ... Ah but that s why you need to integrate it into your build system. That s why I wrote jslint4java. If you commit bad JavaScript then you break the build.
          Message 4 of 11 , Aug 21 8:26 AM
          • 0 Attachment
            On Fri, Aug 21, 2009 at 3:24 PM, Arthur Blake <arthur.blake@...>wrote:

            > Oh, and one other good reason: The comment serves as a reminder that the
            > file should really be checked via jslint whenever it is modified (getting
            > other developers that work on the same code base to validate their code is
            > sometimes like pulling teeth.)
            >

            Ah but that's why you need to integrate it into your build system. That's
            why I wrote jslint4java. If you commit bad JavaScript then you break the
            build. And the axe-wielding project-manager comes a-knocking. :)

            -Dom


            [Non-text portions of this message have been removed]
          • pauanyu
            ... Fair enough, but your comments don t really apply to me, so I am still kindly asking for a longer-length cookie.
            Message 5 of 11 , Aug 21 12:06 PM
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
              >
              > Just expressing my humble opinion... another few good reasons:
              > 1. your code can be used in other JSLint environments (instead of just the
              > web front end) and be validated consistently. For example, build tools,
              > like jslint4java.
              > 2. If you have one or two modules that just have to use eval, you can turn
              > on the evil flag (or any other flag), yet turn it off for all the other
              > files. That way you don't have to remember to manually change the setting.
              > 3. Even if it's dozens and dozens of files, you can gradually add the header
              > to each file as you touch them, that's what I'm doing with my hundreds of JS
              > files.
              >

              Fair enough, but your comments don't really apply to me, so I am still kindly asking for a longer-length cookie.
            • altearius
              I am also in favor of returning the previous functionality of the long-term cookie. Maintaining a /*jslint*/ block at the top of every JavaScript file that I
              Message 6 of 11 , Aug 21 4:18 PM
              • 0 Attachment
                I am also in favor of returning the previous functionality of the long-term cookie.

                Maintaining a /*jslint*/ block at the top of every JavaScript file that I am interested in is tedious. There is a significant maintenance burden associated with adding this block to all currently existing files. Moreover, since I started using JSLint, the list of possible options for the /*jslint*/ block has seen several new additions. I see no reason to suspect that the current list of options will remain unchanged forever. If I want my JavaScript files to be validated against new additions in the future, I would then need to remember to update the /*jslint*/ block, or I would need to remember to check the checkbox. It's too easy to forget something like that. Such a mistake would feel similar to forgetting to use hasOwnProperty, or forgetting to declare a variable with var before using it: it's the kind of mistake that JSLint could be helping us to prevent.

                Also, having a /*jslint*/ block at the top of each file opens the door to another class of errors. I would never copy and paste from one file into another, but my coworkers certainly will. Imagine that I have a file that requires the use of eval, and my /*jslint*/ block says so. If EVERY JavaScript file is now required to use a /*jslint*/ block to validate through JSLint, I can bet that I'll start seeing that /*jslint evil: true */ block start propagating around. Yes, it's really a training issue, but copy-paste coders are an awfully persistent problem. If they are faced with either manually checking these checkboxes, or copy-pasting a /*jslint*/ block from somewhere else, they're going to choose the later (actually, they will first choose to do nothing, at which point I will come berate them for not validating their JavaScript with JSLint).

                Finally, there's that "JSLint will hurt your feelings." warning. When I go to www.jslint.com, paste some code into the big code-accepting text box, I notice that none of the checkboxes are checked. So I go to check one, and poof, the "hurt feelings" warning vanishes, and all those checkboxes jump up the screen. It is disorienting and confusing: not only did my click not make it to the checkbox I was aiming for, but also the checkbox has moved about an inch up from where it was. I am not here to play whack-a-mole! ;)

                - Chris


                --- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
                >
                > IMHO, even nicer and more useful than using the cookie, is simply specifying
                > the jslintoptions at the top of your JS file!
                >
                > Options can also be specified within a script with a /*jslint */ comment:
                > >
                > > /*jslint nomen: true, debug: true,
                > > evil: false, onevar: true */
                > >
                > > An option specification starts with /*jslint. Notice that there is no
                > > space before the j. The specification contains a sequence of name value
                > > pairs, where the names are JSLint options, and the values are true or
                > > false. The indent option <http://www.jslint.com/lint.html#options> can
                > > take a number. A /*jslint */ comment takes precedence over the option
                > > object.
                > >
                >
                > That way you can customize the setting on a per file basis if needed too!
                >
                > On Thu, Aug 20, 2009 at 2:36 AM, pauanyu <pcxunlimited@...> wrote:
                >
                > >
                > >
                > > Previously, the cookie JSLint used to store the settings was a rather
                > > long-lived cookie. Recently, this was changed so the cookie would expire at
                > > the end of the session.
                > >
                > > It is very inconveniencing to have to reset the options every time I close
                > > and reopen my browser. In fact, because the default settings are extremely
                > > lenient, I have made mistakes where I thought my file was valid, when in
                > > fact I had merely forgotten to check the settings.
                > >
                > > I kindly request that the cookie's lifetime be extended to at least 1 week.
                > >
                > >
                > >
                >
                >
                > [Non-text portions of this message have been removed]
                >
              • pauanyu
                ... It appears that cookies are now saved for ~12 days. Thanks, Douglas!
                Message 7 of 11 , Aug 21 11:20 PM
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
                  >
                  > Previously, the cookie JSLint used to store the settings was a rather long-lived cookie. Recently, this was changed so the cookie would expire at the end of the session.
                  >
                  > It is very inconveniencing to have to reset the options every time I close and reopen my browser. In fact, because the default settings are extremely lenient, I have made mistakes where I thought my file was valid, when in fact I had merely forgotten to check the settings.
                  >
                  > I kindly request that the cookie's lifetime be extended to at least 1 week.
                  >

                  It appears that cookies are now saved for ~12 days. Thanks, Douglas!
                • Jeremy Vinding
                  ... I, personally, do maintain a /*jslint*/ block at the top of every one of my many dozens of files... Thanks to tools like perl, I have not found it
                  Message 8 of 11 , Aug 26 8:39 AM
                  • 0 Attachment
                    > Maintaining a /*jslint*/ block at the top of every JavaScript file
                    > that I am interested in is tedious. There is a significant
                    > maintenance burden associated with adding this block to all
                    > currently existing files. Moreover, since I started using JSLint,
                    > the list of possible options for the /*jslint*/ block has seen
                    > several new additions. I see no reason to suspect that the current
                    > list of options will remain unchanged forever. If I want my
                    > JavaScript files to be validated against new additions in the
                    > future, I would then need to remember to update the /*jslint*/
                    > block, or I would need to remember to check the checkbox. It's too
                    > easy to forget something like that. Such a mistake would feel
                    > similar to forgetting to use hasOwnProperty, or forgetting to
                    > declare a variable with var before using it: it's the kind of
                    > mistake that JSLint could be helping us to prevent.
                    >
                    >
                    I, personally, do maintain a /*jslint*/ block at the top of every one
                    of my many dozens of files... Thanks to tools like perl, I have not
                    found it difficult to keep them up to date at all. Of course, I never
                    actually use the website, I run jslint through JavaScriptCore directly
                    from my editor, and again with rhino as a SVN pre-commit hook, so
                    there are no checkboxes for me.

                    > Also, having a /*jslint*/ block at the top of each file opens the
                    > door to another class of errors. I would never copy and paste from
                    > one file into another, but my coworkers certainly will. Imagine that
                    > I have a file that requires the use of eval, and my /*jslint*/ block
                    > says so. If EVERY JavaScript file is now required to use a /
                    > *jslint*/ block to validate through JSLint, I can bet that I'll
                    > start seeing that /*jslint evil: true */ block start propagating
                    > around. Yes, it's really a training issue, but copy-paste coders are
                    > an awfully persistent problem. If they are faced with either
                    > manually checking these checkboxes, or copy-pasting a /*jslint*/
                    > block from somewhere else, they're going to choose the later
                    > (actually, they will first choose to do nothing, at which point I
                    > will come berate them for not validating their JavaScript with
                    > JSLint).
                    >

                    for cases like this I use the same /*jslint*/ block at the top of the
                    file as I do for every other file, then I enable the evilness just for
                    the line that needs it, eg:

                    /*jslint evil:true*/
                    data = (new Function( "return " + data ))();
                    /*jslint evil:false*/


                    --jjv
                  • Arthur Blake
                    Nice technique! I wasn t aware that was possible. Thanks! ... [Non-text portions of this message have been removed]
                    Message 9 of 11 , Aug 26 9:22 AM
                    • 0 Attachment
                      Nice technique! I wasn't aware that was possible. Thanks!

                      On Wed, Aug 26, 2009 at 11:39 AM, Jeremy Vinding <yui@...>wrote:

                      > for cases like this I use the same /*jslint*/ block at the top of the
                      > file as I do for every other file, then I enable the evilness just for
                      > the line that needs it, eg:
                      >
                      > /*jslint evil:true*/
                      > data = (new Function( "return " + data ))();
                      > /*jslint evil:false*/
                      >
                      > --jjv
                      >
                      >
                      >


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