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

Re: Several issues I hit when using JSLint

Expand Messages
  • 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 1 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.