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

Re: [jslint] The library underscore

Expand Messages
  • Martin Cooper
    ... I agree. The same problem is encountered by everyone using Node.js who also wants to use JSLint, because Node.js creates the predefined variables __dirname
    Message 1 of 4 , Mar 3, 2012
    • 0 Attachment
      On Sat, Mar 3, 2012 at 4:42 PM, Rob Richardson <erobrich@...> wrote:
      > The library underscore.js (http://documentcloud.github.com/underscore/)
      > exports a single variable: _ -- a single underscore.  I've tried putting _
      > in my /*global _ */ declaration but until I "tolerate dangling _ in
      > identifiers", it's still seen as an error.  I grant this library is
      > unfortunately named, but I have little control over that.  I also don't want
      > to blatantly accept all leading underscores as I concur that variables such
      > as "_myvar" are not effectively named.  I propose we implement one or both
      > of these alterations to JSLint:
      >
      > 1. When the variable is in the global list, this should trump the other
      > rules.

      I agree. The same problem is encountered by everyone using Node.js who
      also wants to use JSLint, because Node.js creates the predefined
      variables __dirname and __filename. Douglas's response, when I
      reported that as an issue, was "Take your complaint to Nodejs".

      https://github.com/douglascrockford/JSLint/issues/88

      --
      Martin Cooper


      > 2. If the entirety of the variable is a single underscore, it should not be
      > considered "dangling" as removing this underscore leaves the code more
      > broken.
      >
      > Rob
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
    • douglascrockford
      ... Did you?
      Message 2 of 4 , Mar 3, 2012
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:

        > I agree. The same problem is encountered by everyone using Node.js who
        > also wants to use JSLint, because Node.js creates the predefined
        > variables __dirname and __filename. Douglas's response, when I
        > reported that as an issue, was "Take your complaint to Nodejs".
        >
        > https://github.com/douglascrockford/JSLint/issues/88


        Did you?
      • Martin Cooper
        ... No, I did not. Converting everyone else s JavaScript to The Good Parts is not my crusade. As I said in the ticket, my goal is to ensure that the code that
        Message 3 of 4 , Mar 10, 2012
        • 0 Attachment
          On Sat, Mar 3, 2012 at 9:37 PM, douglascrockford <douglas@...> wrote:
          > --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
          >
          >> I agree. The same problem is encountered by everyone using Node.js who
          >> also wants to use JSLint, because Node.js creates the predefined
          >> variables __dirname and __filename. Douglas's response, when I
          >> reported that as an issue, was "Take your complaint to Nodejs".
          >>
          >> https://github.com/douglascrockford/JSLint/issues/88
          >
          >
          > Did you?

          No, I did not. Converting everyone else's JavaScript to The Good Parts
          is not my crusade.

          As I said in the ticket, my goal is to ensure that the code that *my*
          team writes conforms to The Good Parts, because I believe that's the
          right thing for my team to be doing. But I should not have to choose
          between turning off enforcement of a recommended practice, or
          littering our code with special comments, just because the developer
          of a 3rd party dependency made a decision to use different naming
          conventions.

          Those of us writing real production code very rarely have the luxury
          of writing every line of code ourselves. Thus we rely on libraries and
          toolkits written by others. JSLint should not be penalising us for
          using code that is not under our control, and it's neither realistic
          nor pragmatic to tell us to go convince each of our dependencies that
          they're using the "wrong" coding conventions.

          --
          Martin Cooper
        Your message has been successfully submitted and would be delivered to recipients shortly.