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

option.type

Expand Messages
  • Douglas Crockford
    JSLint is now starting to do type inference. It reports cases were variables are used to house multiple types. This is still very early, so there are many
    Message 1 of 9 , Jun 2, 2011
    View Source
    • 0 Attachment
      JSLint is now starting to do type inference. It reports cases were variables are used to house multiple types. This is still very early, so there are many cases which are not yet detected.

      The warning is "Type inconsistency: {a} and {b}." where the {a} and {b} will be replaced with the names of types. It is usually easy to see what caused the warning. In some cases, it can be very puzzling. In the puzzling cases, try initializing your vars with typed values. For example, if you expect that n will contain numbers, then write

      var n = 0;

      That should produce clearer warnings.

      Type inconsistency is not necessarily an error, particularly in a language that provides as much type freedom as this one does. But some inconsistencies are errors, so type discipline might be something to consider adding to your programming style. Also, the fastest JavaScript engines will slow down in the presence of type inconsistency.

      To turn off these warnings, turn on the new Tolerate type inconsistency option, or set option.type to true.
    • Douglas Crockford
      Has anyone tried the new type consistency checking? Has anyone found it to be useful?
      Message 2 of 9 , Jun 5, 2011
      View Source
      • 0 Attachment
        Has anyone tried the new type consistency checking?
        Has anyone found it to be useful?
      • Martin Cooper
        ... Inadvertently, yes. :) It highlighted some strange code of the form: if (false == filePath) { ... var cmd = cd + filePath; (I don t know why the test
        Message 3 of 9 , Jun 5, 2011
        View Source
        • 0 Attachment
          On Sun, Jun 5, 2011 at 6:18 PM, Douglas Crockford <douglas@...> wrote:
          > Has anyone tried the new type consistency checking?

          Inadvertently, yes. :) It highlighted some strange code of the form:

          if (false == filePath) {
          ...
          var cmd = 'cd ' + filePath;

          (I don't know why the test was written like that.)

          In this particular case, it would have been caught in code review, but
          JSLint did call attention to a function argument being tested as
          Boolean and then used as String.

          > Has anyone found it to be useful?

          Debatable in this case, because it was sufficiently obvious already,
          but potentially useful.

          --
          Martin Cooper


          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
        • John Hawkinson
          Douglas Crockford wrote on Mon, 6 Jun 2011 ... This consequence appears to be undesirable: Problem at line 1 character 34: Type
          Message 4 of 9 , Jun 5, 2011
          View Source
          • 0 Attachment
            Douglas Crockford <douglas@...> wrote on Mon, 6 Jun 2011
            at 01:18:59 -0000 in <ish9u3+tj8c@...>:

            > Has anyone tried the new type consistency checking?
            > Has anyone found it to be useful?

            This consequence appears to be undesirable:

            Problem at line 1 character 34: Type inconsistency: string and number.

            var mixed="The value is three ("+3+")";

            An oversimplified example, but it's common to mix strings and numbers
            together knowing that the numbers will be converted to string.

            Also true for strings + booleans. It seems to fire on a lot of
            debugging statements in my code.

            --jhawk@...
            John Hawkinson
          • 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 5 of 9 , Jun 6, 2011
            View Source
            • 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 6 of 9 , Jun 6, 2011
              View Source
              • 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 7 of 9 , Jun 6, 2011
                View Source
                • 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 8 of 9 , Jun 6, 2011
                  View Source
                  • 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 9 of 9 , Jun 6, 2011
                    View Source
                    • 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.