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

Re: [jslint] Re: option.type

Expand Messages
  • mathew
    ... It s a habit some programmers like to get into, because in C or Java if you forget one of the = signs by mistake you get a compile-time failure rather
    Message 1 of 9 , Jun 6, 2011
    • 0 Attachment
      On Sun, Jun 5, 2011 at 21:01, Martin Cooper <mfncooper@...> wrote:

      > if (false == filePath) {
      > ...
      > var cmd = 'cd ' + filePath;
      >
      > (I don't know why the test was written like that.)
      >

      It's a habit some programmers like to get into, because in C or Java if you
      forget one of the '=' signs by mistake you get a compile-time failure rather
      than a runtime error.

      This doesn't apply in JavaScript, of course, though you're at least
      guaranteed an obvious runtime error rather than a subtle one.


      mathew
      --
      <URL:http://www.pobox.com/~meta/>


      [Non-text portions of this message have been removed]
    • spence.randall@ymail.com
      ... I gave it a try, and I was fully expecting to see a mass of errors, but was pleasantly surprised when I only had one. ... In the case of the actual error
      Message 2 of 9 , Jun 6, 2011
      • 0 Attachment
        > Has anyone tried the new type consistency checking?

        I gave it a try, and I was fully expecting to see a mass of errors, but was pleasantly surprised when I only had one.

        > Has anyone found it to be useful?

        In the case of the actual error it flagged, I'm not sure. It was a "value" parameter in a setStyle function that could either be a string or a number. If the property that was being set was opacity and the browser was determined to be IE, it multiplies the value by 100 to get the proper setting for the filter. In this case wrapping the calculation in String() appears to satisfy JSLint. Would this be the proper approach?

        -Randall
      • Erik Eckhardt
        I think it s value.toString() not String(value). Correct me if I m wrong. On Mon, Jun 6, 2011 at 2:48 PM, spence.randall@ymail.com
        Message 3 of 9 , Jun 6, 2011
        • 0 Attachment
          I think it's value.toString() not String(value). Correct me if I'm wrong.

          On Mon, Jun 6, 2011 at 2:48 PM, spence.randall@... <
          randall@...> wrote:

          >
          >
          >
          >
          > > Has anyone tried the new type consistency checking?
          >
          > I gave it a try, and I was fully expecting to see a mass of errors, but was
          > pleasantly surprised when I only had one.
          >
          >
          > > Has anyone found it to be useful?
          >
          > In the case of the actual error it flagged, I'm not sure. It was a "value"
          > parameter in a setStyle function that could either be a string or a number.
          > If the property that was being set was opacity and the browser was
          > determined to be IE, it multiplies the value by 100 to get the proper
          > setting for the filter. In this case wrapping the calculation in String()
          > appears to satisfy JSLint. Would this be the proper approach?
          >
          > -Randall
          >
          >
          >


          [Non-text portions of this message have been removed]
        • spence.randall@ymail.com
          Here is the code snippet in question: Original: element.style.filter = alpha(opacity= + value * 100 + ) ; Error: Type inconsistency: string and number with
          Message 4 of 9 , Jun 6, 2011
          • 0 Attachment
            Here is the code snippet in question:

            Original:
            element.style.filter = 'alpha(opacity=' + value * 100 + ')';
            Error: Type inconsistency: string and number

            with String():
            element.style.filter = 'alpha(opacity=' + String(value * 100) + ')';
            No error.

            with .toString():
            element.style.filter = 'alpha(opacity=' + (value * 100).toString() + ')';
            Also no error. I think this may make the intention of the code clearer.

            Either method produces the expected result.

            -Randall








            --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
            >
            > I think it's value.toString() not String(value). Correct me if I'm wrong.
            >
            > On Mon, Jun 6, 2011 at 2:48 PM, spence.randall@... <
            > randall@...> wrote:
            >
            > >
            > >
            > >
            > >
            > > > Has anyone tried the new type consistency checking?
            > >
            > > I gave it a try, and I was fully expecting to see a mass of errors, but was
            > > pleasantly surprised when I only had one.
            > >
            > >
            > > > Has anyone found it to be useful?
            > >
            > > In the case of the actual error it flagged, I'm not sure. It was a "value"
            > > parameter in a setStyle function that could either be a string or a number.
            > > If the property that was being set was opacity and the browser was
            > > determined to be IE, it multiplies the value by 100 to get the proper
            > > setting for the filter. In this case wrapping the calculation in String()
            > > appears to satisfy JSLint. Would this be the proper approach?
            > >
            > > -Randall
            > >
            > >
            > >
            >
            >
            > [Non-text portions of this message have been removed]
            >
          • Joshua Bell
            ... If value might be undefined or null you re better off using String(value). ... On the thread in general... Running some of my code through JSLint I m
            Message 5 of 9 , Jun 6, 2011
            • 0 Attachment
              On Mon, Jun 6, 2011 at 3:08 PM, Erik Eckhardt <erik@...> wrote:

              > I think it's value.toString() not String(value). Correct me if I'm wrong.


              If value might be undefined or null you're better off using String(value).

              ...

              On the thread in general...

              Running some of my code through JSLint I'm (thankfully) seeing only a few
              occurrences of the "Type inconsistency" error:

              * One case where an optional argument is being tested against undefined then
              used in a string context:

              function f(a) {
              if (a !== (void 0)) {
              return "foo: " + a;
              }
              else {
              return "foo";
              }
              }

              Note that if the test is against the identifier "undefined" then the error
              goes away, it's only the "(void 0)" construction that triggers it. (I'm
              weird and don't trust the window.undefined property which is writable in
              some browsers.) This indicates that there's likely a special case for
              testing against undefined already. Arguably (pun intended) my code could
              test against arguments.length instead.

              * Construction of exception messages where a number is being concatenated
              into a string. In this case, wrapping with String() resolves the warning and
              probably improves maintainability of the code.

              * Cases where the variable is being used to hold different types, e.g. a
              string or number, and not in a type-agnostic context:

              var default_value = (var_type === 'string') ? '' : 0;

              These are infrequent enough that I can wrap them in a function and mark it
              with /*jslint type:true*/ to indicate the intent.


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