JSLint Reports on last 2 Production Versions of jQuery
in [JavaScript]
|
Prev: FAQ Entry Proposal: What is (function(){ /*...*/ })() ?
Next: FAQ Topic - What is Ajax? (2010-03-01)
From: Andrea Giammarchi on 5 Mar 2010 06:45 On Mar 5, 12:37 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > If a developer doesn't understand JSLint's warnings then it > is probably a good idea for them to be following its > suggestions. that's for sure, but still trying to understand why and not just considering it "correct" in its absolute meaning. > The point of the second suggestion is to use '===', not > '=== undefined' specifically. Both are suggestions are good > advice. no, these are not good suggestions if the reason is: "compare via == causes coercion" There are cases and cases and null and undefined are a special case. Moreover it could be extremely dangerous to rely in undefined variable (which costs lookup as well) > I'd say that was 5 minutes well spent. Running a colleague's > code through JSLint and then explaining the warnings to them > is a good investment. --Antony Agreed, except yoou have to repeat yourself every time you meant something ... and you would like to be able to validate against a validation tool, so it should be "almost perfect" while this == null is the most annoying thing ever to me. Regards
From: Antony Scriven on 5 Mar 2010 07:41 On Mar 5, 11:45am, Andrea Giammarchi wrote: > On Mar 5, 12:37pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > [...] > > > The point of the second suggestion is to use '===', not > > '=== undefined' specifically. Both are suggestions are good > > advice. > > no, these are not good suggestions if the reason is: > "compare via == causes coercion" There are cases and > cases and null and undefined are a special case. null !== undefined as you well know. > Moreover it could be extremely dangerous to rely in > undefined variable (which costs lookup as well) Yes, I agree. That was the first suggestion I was referring to; you snipped that. > > I'd say that was 5 minutes well spent. Running a colleague's > > code through JSLint and then explaining the warnings to them > > is a good investment. --Antony > > Agreed, except yoou have to repeat yourself every time > you meant something [...] I've not found that in my experience. --Antony
From: Andrea Giammarchi on 5 Mar 2010 08:20 On Mar 5, 1:41 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > null !== undefined as you well know. Antony, that is true, but null == undefined does not cause coercion the suggestion means. null == {valueOf:function(){return null}} is FALSE while 1 == {valueOf:function(){return 1}} is TRUE I do believe this is the coercion JSLint talks about, nothing to do with specified behaviors We could say the undefined internal prototype is null so it's normal to me that null == undefined and, again, undefined is not a proper value to rely on. It is surely strictly different "!==" from null, which is a static constant as true or false (safer 'cause we cannot reassign it) but in most of the case we don't need the undefined "concept" sicne == null is all we need to understand if a variable has been defined or it is exactly null (arguments, properties, etc) In few words, 99% of the time that is what we want to check, 1% is a strict operation for those that decided that null and undefined have different meanings (bad design, imho) This is what I am complaining about, that warning should be clearer, it should be a NOTICE rather than a warning, or it should be possible to disable. Then we have other gotchas ... but this is another story. > I've not found that in my experience. --Antony Have you ever tried to validate against JSLint before the build? ... it is not possible right now to remove that bloody warning and warnings for non teachy people are never welcome. Regards
From: Scott Sauyet on 5 Mar 2010 10:01 Richard Cornford wrote: > On Mar 4, 4:28 pm, Scott Sauyet wrote: >> Richard Cornford wrote: >> It's possible that this is the case. But my take is that the >> quality of JS found around the web is better than it was before >> the onset of the GP libraries. > > While my impression is that it is about the same. > >> There are still plenty of really poor scripts floating around >> (and I'm talking about ones that make jQuery et al >> look positively brilliant) > > What about the really poor scripts that use JQuery et al? > >> but they no longer get the exposure they used to, as it's >> become so easy to achieve what these sometimes massive >> one-off scripts did using only line or two of jQuery-based >> code. (Dojo, MooTools, YUI, whatever.) > > The "massive" one-of scripts you refer to (at least the better of > them) tended to be designed to be copied into a web page and then > given a "line or two" of configuration. There is not that much > difference between doing that and using a general purpose library, > except that the one-off script likely did not contain much that it did > not use, but the general purpose library will contain some that is not > used in any equivalent task. I wish I could remember its name, but I remember having to remove a 150K animation script from a site. All it did was animate positions and sizes. It was littered with "if (document.layers)" and "if (document.all)", and worse, it required the user to add those same guards to sections of their own code. It was easy enough to replace with a small custom script, and it was replaced at a time when the client didn't care about the version 4 browsers, so the code was reasonably clean. But what I remember most about it was that this was a *popular* script. I simply haven't seen that sort of thing with the GP libraries. I've seen plenty of new gratuitous use of animations in pages because they already include, say, dojo, and it's so easy to just add an animation now. But I haven't seen the kind of nonsense that requires a new release of the script on every point release of a browser. One might not like the APIs provided by these GP libraries, but they do usually provide APIs straightforward enough that the code that uses them is simple to write and comprehend. In many site, the worst problem of code using JQuery is often the relatively innocuous failure to cache the JQuery objects created, running queries over and over. I'm not trying to say there is no bad code written by users of GP libraries. There is certainly some horrendous stuff. But I'm seeing much less awful code today than five years ago. > I do see libraries such as JQuery superseding the copy-n-paste script > collections of the past, but only in that they provide the equivalent; > a source of example code that people who don't know what they are > doing can copy and paste into their own pages, achieve a 'working' > outcome, and elaborate through repletion. Indeed, I see that as the "elaborate through repletion"? > best (if not the only) way in which any new library will achieve > 'popularity'. Technical quality will always be largely irrelevant (so > long is it isn't so bad that it is obviously non-functional on common > browsers) because the people looking for a 'solution' to their problem > cannot judge that aspect, while the (relative) ease of pasting an > example into a working context is something that can easily be judged. I'm trying to figure out what it is about the Web that makes this problem so much more severe than in other development environments. It certainly seems to be so. Ease of use trumps other measure of quality all the time in web development. Any thoughts on why? > [ ... ] I was thinking in terms of > people's perceptions of their own abilities. I have observed before > that early superficial success (often following earlier frustration) > with the language seems to result in a quite unjustified > overconfidence in ones own abilities, and that while suffering that > overconfidence it becomes difficult to learn/advance [ ... ] And, as you say, this becomes especially problematic if people so stuck become influential. There is of course a large spectrum of ability in almost any field of endeavor. With web technologies, including JS, it does seem that at lot more people without particularly advanced skills do see themselves as extremely knowledgeable. Perhaps its the number of amateurs involved. There aren't that many people who aren't professional programmers or academics trying to implement a tricky cryptography algorithm in C++. But the church's website might well be entirely maintained by someone who learned most of their web technologies by cutting and pasting from sties they like. And even those of us who are professional are not necessarily as advanced as we might like. I personally have become involved with c.l.j.s. because I know that I was missing some fundamentals. For my last few positions, I've been the go-to-guy on the team for JS issues. In some cases, I could come up with working solutions to problems even though I didn't understand all of the underlying principles thoroughly. I figured that here, I would be able to contribute and learn at the same time. For those people who think they're beyond that, the only hope I have is that they'll be jolted out of their complacency when they actually do get in over their heads and somebody shows how much they still have to learn. >> Of course [GP library users trying to advance will] have >> unlearning to do. But most advancement involves some >> degree of unlearning. > > But what if the things that they unlearn include the opinion that > starting out using a general purpose liberally was a good idea? :-) They might. That's a harsher lesson than they might be ready for, but if it really is the case, presumably they'll eventually learn it as they advance. [ ... much other interesting discussion deleted, as I really have to get back to work ... ] -- Scott
From: Antony Scriven on 5 Mar 2010 10:08
On Mar 5, 1:20pm, Andrea Giammarchi wrote: > On Mar 5, 1:41pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > > null !== undefined as you well know. > > Antony, that is true, but null == undefined does not > cause coercion the suggestion means. == can cause type coercion even if it doesn't in all cases. And type coercion to boolean wouldn't change the the semantics of null == undefined. I think you are dwelling too much on the wording here. It might be worth noting that searching for the word 'coercion' in the standard brings back Number(null) matches (and not Number(undefined) matches). > [...] > most of the case we don't need the undefined "concept" > sicne == null is all we need to understand if a variable > has been defined or it is exactly null (arguments, > properties, etc) Yes but these are different things. One possible problem could be thinking that a variable holds the value null when really you forgot to initialise it. > In few words, 99% of the time that is what we want to > check, 1% is a strict operation for those that decided > that null and undefined have different meanings (bad > design, imho) But they do have different meanings. There is a problem of intent here. If I'm reading your code and I see 'if(x==null)', then I don't know if you really did mean 'if(x === null || typeof x == "undefined")' or if you made a mistake. It might be more convenient for you to write, but not for anyone who has to read it. > This is what I am complaining about, that warning should > be clearer, it should be a NOTICE rather than a warning, > or it should be possible to disable. I think this is covered by the following warning: 'JSLint will hurt your feelings.' > [...] > > Have you ever tried to validate against JSLint before the > build? Yes. > ... it is not possible right now to remove that > bloody warning and warnings for non teachy people are > never welcome. Don't take it too personally, it's only a tool. And I can think of one easy way to remove the warning. :-) --Antony |