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

Several issues I hit when using JSLint

Expand Messages
  • caerusx
    Hi I m new to javascript, but I have a solid C/C++ background. One of reasons why I prefer C++ over C is because it stricter. I prefer to catch errors during
    Message 1 of 3 , Jan 22, 2012
    • 0 Attachment
      Hi

      I'm new to javascript, but I have a solid C/C++ background. One of
      reasons why I prefer C++ over C is because it stricter. I prefer to
      catch errors during compile time rather in run time. That's why I
      addressed to JSLint. Thanks to Douglas Crockford's for creating JSLint!

      During use of JSLint I hit several issues, I want to discuss.

      1. JSLint does not handle functions with circular dependencies well.

      Let I have following code:

      var f1 = function () { f2(); },
      f2 = function () { f1(); };

      JSLint won't validate this code, with the reason that 'f2' is not yet
      defined. But I think it is a valid code. As far as I understand, all
      variables declarations inside function are visible by javascript
      engine regardless of declaration order and are subject to closure
      capturing. So the code is roughly equivalent to:

      var f1, f2;

      f1 = function () { f2(); };
      f2 = function () { f1(); };

      I think it would be nice if JSLint will make a distinction, whenever
      variable is used directly or used in closure. So it will reject code
      like:

      var v = f() + 1,
      f = function () { return 1; };

      But still allow code like mine.

      When making a closure, it is important that variable must be declared,
      but order is not important, variable can be declared everywhere inside
      function.

      When variable value is actually used (not with closure), then it is
      really important to check that it was set before.

      2. Why ++ operator is banned? (Sorry for raising this question again).

      As I mentioned before I've been working with C/C++ many years. And
      when I see p += 1 inside a loop it hurts my eyes.

      I tried to figure out why these operators are fallen out of favor. I
      read discussions, I watched Douglas Crockford's lectures. But I still
      don't really understand what is bad in ++ operator.

      Douglas reasons banning of operators because they are too error
      prone. But I think that not these operators are error prone as the way
      they used.

      People are often made mistakes when operators are used inside an
      expression. That's the real problem. So why to ban whole operator
      rather then ban it's dangerous usage. It's pretty safe to use
      operators when result is ignored: when expression statement is a
      single inc/dec operator or when inc/dec operator is a part of comma
      expression which value is ignored (like expression statement, or third
      expression in 'for' loop).

      Douglas suggests to use p += 1 instead of ++p, but I don't see any
      safety benefits. They are almost equivalent. You may literally replace
      every ++p with (p += 1) but bugs wouldn't be magically cured. The only
      difference is operator precedence. But precedence does not matter, if
      increment operators are allowed only in cases where result is ignored.

      I think it is not fair to ban innocent operators, better to catch the
      situations where result of (p += 1) or ++p or p++ is actually used.

      Thank you for attention!

      PS. Funny thing that Google's javascript linter, gjslint doesn't like
      space between function keyword and opening brace. So it is impossible
      to make a source which makes both linters happy.

      (Personally I agree with JSLint, it is consistent to add a space
      between language keyword and opening brace. If you write "if (",
      "while (", "switch (", ..., why to omit space with function keyword?).
    • Benjamin Gandon
      Hi caerusx, hi everyone, I am new to the list too, so I m not (yet) tired of answering the (easy) ++ question, so I ll answer. 1. I would personally say that
      Message 2 of 3 , Jan 23, 2012
      • 0 Attachment
        Hi caerusx, hi everyone,

        I am new to the list too, so I'm not (yet) tired of answering the (easy)
        ++ question, so I'll answer.

        1.
        I would personally say that your 2nd version is better. It better shows
        you understand that you are capturing those variables. It better
        expresses that you understand what you write. First declare, then use.

        2.
        There is an error prone + unary operator that converts a number into a
        string.
        Sure you always write you loops like this one:

        for (var i = 0; i < 10; ++i) { document.write("hello"); }

        but if you unfortunately insert a space between the two +, it is still
        valid JavaScript:

        for (var i = 0; i < 10; + +i) { document.write("hello"); }

        Though it won't do the same thing at all, looping forever.
        That's why jslint complains with the two unary operators: + and ++.
        I personally always disable the warning. But I should not.

        /Benjamin


        On 22/01/2012 13:09, caerusx wrote:
        >
        > Hi
        >
        > I'm new to javascript, but I have a solid C/C++ background. One of
        > reasons why I prefer C++ over C is because it stricter. I prefer to
        > catch errors during compile time rather in run time. That's why I
        > addressed to JSLint. Thanks to Douglas Crockford's for creating JSLint!
        >
        > During use of JSLint I hit several issues, I want to discuss.
        >
        > 1. JSLint does not handle functions with circular dependencies well.
        >
        > Let I have following code:
        >
        > var f1 = function () { f2(); },
        > f2 = function () { f1(); };
        >
        > JSLint won't validate this code, with the reason that 'f2' is not yet
        > defined. But I think it is a valid code. As far as I understand, all
        > variables declarations inside function are visible by javascript
        > engine regardless of declaration order and are subject to closure
        > capturing. So the code is roughly equivalent to:
        >
        > var f1, f2;
        >
        > f1 = function () { f2(); };
        > f2 = function () { f1(); };
        >
        > I think it would be nice if JSLint will make a distinction, whenever
        > variable is used directly or used in closure. So it will reject code
        > like:
        >
        > var v = f() + 1,
        > f = function () { return 1; };
        >
        > But still allow code like mine.
        >
        > When making a closure, it is important that variable must be declared,
        > but order is not important, variable can be declared everywhere inside
        > function.
        >
        > When variable value is actually used (not with closure), then it is
        > really important to check that it was set before.
        >
        > 2. Why ++ operator is banned? (Sorry for raising this question again).
        >
        > As I mentioned before I've been working with C/C++ many years. And
        > when I see p += 1 inside a loop it hurts my eyes.
        >
        > I tried to figure out why these operators are fallen out of favor. I
        > read discussions, I watched Douglas Crockford's lectures. But I still
        > don't really understand what is bad in ++ operator.
        >
        > Douglas reasons banning of operators because they are too error
        > prone. But I think that not these operators are error prone as the way
        > they used.
        >
        > People are often made mistakes when operators are used inside an
        > expression. That's the real problem. So why to ban whole operator
        > rather then ban it's dangerous usage. It's pretty safe to use
        > operators when result is ignored: when expression statement is a
        > single inc/dec operator or when inc/dec operator is a part of comma
        > expression which value is ignored (like expression statement, or third
        > expression in 'for' loop).
        >
        > Douglas suggests to use p += 1 instead of ++p, but I don't see any
        > safety benefits. They are almost equivalent. You may literally replace
        > every ++p with (p += 1) but bugs wouldn't be magically cured. The only
        > difference is operator precedence. But precedence does not matter, if
        > increment operators are allowed only in cases where result is ignored.
        >
        > I think it is not fair to ban innocent operators, better to catch the
        > situations where result of (p += 1) or ++p or p++ is actually used.
        >
        > Thank you for attention!
        >
        > PS. Funny thing that Google's javascript linter, gjslint doesn't like
        > space between function keyword and opening brace. So it is impossible
        > to make a source which makes both linters happy.
        >
        > (Personally I agree with JSLint, it is consistent to add a space
        > between language keyword and opening brace. If you write "if (",
        > "while (", "switch (", ..., why to omit space with function keyword?).
        >
        > __._,_._
        >
        >


        [Non-text portions of this message have been removed]
      • caerusx
        Hi Thanks for answer! It makes a sense. But += operator is vulnerable to character swap typo, i =+ 1 is also valid javascript expression. The unary
        Message 3 of 3 , Jan 23, 2012
        • 0 Attachment
          Hi

          Thanks for answer!

          It makes a sense. But '+=' operator is vulnerable to character swap
          typo, 'i =+ 1' is also valid javascript expression.

          The unary operators are really evil. Unary plus operator is used
          either accidentally or as a hack (in C++ to trigger decaying of array
          or implicit conversion to int, in Perl to emphasize that construction
          is really an expression looks like a block but not a real block, and
          as shorthand to parseInt in JavaScript). Unary minus is actually used,
          but usage is very rare (probably programmers writing computational
          programs encounter it more often).

          Better to ban unary operators. I think ban of unary plus operator most
          users would go unnoticed, and unary minus can be easily rewritten as
          (0 - i).


          --- In jslint_com@yahoogroups.com, Benjamin Gandon <benje@...> wrote:
          >
          > Hi caerusx, hi everyone,
          >
          > I am new to the list too, so I'm not (yet) tired of answering the (easy)
          > ++ question, so I'll answer.
          >
          > 1.
          > I would personally say that your 2nd version is better. It better shows
          > you understand that you are capturing those variables. It better
          > expresses that you understand what you write. First declare, then use.
          >
          > 2.
          > There is an error prone + unary operator that converts a number into a
          > string.
          > Sure you always write you loops like this one:
          >
          > for (var i = 0; i < 10; ++i) { document.write("hello"); }
          >
          > but if you unfortunately insert a space between the two +, it is still
          > valid JavaScript:
          >
          > for (var i = 0; i < 10; + +i) { document.write("hello"); }
          >
          > Though it won't do the same thing at all, looping forever.
          > That's why jslint complains with the two unary operators: + and ++.
          > I personally always disable the warning. But I should not.
          >
          > /Benjamin
          >
          >
          > On 22/01/2012 13:09, caerusx wrote:
          > >
          > > Hi
          > >
          > > I'm new to javascript, but I have a solid C/C++ background. One of
          > > reasons why I prefer C++ over C is because it stricter. I prefer to
          > > catch errors during compile time rather in run time. That's why I
          > > addressed to JSLint. Thanks to Douglas Crockford's for creating JSLint!
          > >
          > > During use of JSLint I hit several issues, I want to discuss.
          > >
          > > 1. JSLint does not handle functions with circular dependencies well.
          > >
          > > Let I have following code:
          > >
          > > var f1 = function () { f2(); },
          > > f2 = function () { f1(); };
          > >
          > > JSLint won't validate this code, with the reason that 'f2' is not yet
          > > defined. But I think it is a valid code. As far as I understand, all
          > > variables declarations inside function are visible by javascript
          > > engine regardless of declaration order and are subject to closure
          > > capturing. So the code is roughly equivalent to:
          > >
          > > var f1, f2;
          > >
          > > f1 = function () { f2(); };
          > > f2 = function () { f1(); };
          > >
          > > I think it would be nice if JSLint will make a distinction, whenever
          > > variable is used directly or used in closure. So it will reject code
          > > like:
          > >
          > > var v = f() + 1,
          > > f = function () { return 1; };
          > >
          > > But still allow code like mine.
          > >
          > > When making a closure, it is important that variable must be declared,
          > > but order is not important, variable can be declared everywhere inside
          > > function.
          > >
          > > When variable value is actually used (not with closure), then it is
          > > really important to check that it was set before.
          > >
          > > 2. Why ++ operator is banned? (Sorry for raising this question again).
          > >
          > > As I mentioned before I've been working with C/C++ many years. And
          > > when I see p += 1 inside a loop it hurts my eyes.
          > >
          > > I tried to figure out why these operators are fallen out of favor. I
          > > read discussions, I watched Douglas Crockford's lectures. But I still
          > > don't really understand what is bad in ++ operator.
          > >
          > > Douglas reasons banning of operators because they are too error
          > > prone. But I think that not these operators are error prone as the way
          > > they used.
          > >
          > > People are often made mistakes when operators are used inside an
          > > expression. That's the real problem. So why to ban whole operator
          > > rather then ban it's dangerous usage. It's pretty safe to use
          > > operators when result is ignored: when expression statement is a
          > > single inc/dec operator or when inc/dec operator is a part of comma
          > > expression which value is ignored (like expression statement, or third
          > > expression in 'for' loop).
          > >
          > > Douglas suggests to use p += 1 instead of ++p, but I don't see any
          > > safety benefits. They are almost equivalent. You may literally replace
          > > every ++p with (p += 1) but bugs wouldn't be magically cured. The only
          > > difference is operator precedence. But precedence does not matter, if
          > > increment operators are allowed only in cases where result is ignored.
          > >
          > > I think it is not fair to ban innocent operators, better to catch the
          > > situations where result of (p += 1) or ++p or p++ is actually used.
          > >
          > > Thank you for attention!
          > >
          > > PS. Funny thing that Google's javascript linter, gjslint doesn't like
          > > space between function keyword and opening brace. So it is impossible
          > > to make a source which makes both linters happy.
          > >
          > > (Personally I agree with JSLint, it is consistent to add a space
          > > between language keyword and opening brace. If you write "if (",
          > > "while (", "switch (", ..., why to omit space with function keyword?).
          > >
          > > __._,_._
          > >
          > >
          >
          >
          > [Non-text portions of this message have been removed]
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.