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: Antony Scriven on 6 Mar 2010 05:52 On Mar 6, 8:48 am, Andrea Giammarchi wrote: > On Mar 5, 4:08 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > [...] > > null is a special case that should be better > described/understood and I don't think a flag able to > tell JSLint "ignore ==null" is such problematic issue > since cases where we need === null are 99% of the time > followed by || x === undefined, which IS an issue, or || > typeof x === "undefined", which is just boring if all we > wanna know is if it is null OR undefined. If you're checking for '=== null' 99% of the time, then write '=== null' 99% of the time. What is boring is debugging code whose intent has not been made clear by the author. --Antony
From: Antony Scriven on 6 Mar 2010 06:03 On Mar 5, 9:47 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > [on JQuery plugin architecture] > > The problem is that other plug-ins might also want to > expose a getDate() method, having nothing to do with > datepicker's version. That's what all this namespacing is > about. We want datepicker to be able to somehow expose > a getDate method, but it shouldn't add more than the > "datepicker" property to the wrapper object. If datepicker() decorates the wrapper object it returns with extra methods then I don't think namespacing would be an issue. > I'm sorry, this is taking more iterations than > I expected. Obviously I didn't explain the idea very > well up front. I think you're explaining your point well; iterations are to be expected. But I think this discussion probably warrants a separate thread if it is to be continued much further. --Antony
From: Andrea Giammarchi on 8 Mar 2010 07:53 On Mar 6, 11:52 am, Antony Scriven <adscri...(a)gmail.com> wrote: > If you're checking for '=== null' 99% of the time, then > write '=== null' 99% of the time. What is boring is > debugging code whose intent has not been made clear by the > author. --Antony I am checking to know if it is undefined or null so I use the "== null" check 'cause I don't want to set null properties in any prototype, it's absolutely pointless. Back at the beginning, it is boring to write every time that I meant it via code. If you don't know == null means === undefined || === null it cannot be other devs fault. We are coder, not monkeys unable to understand basis of the programming language we use on daily basis, the problem is somewhere else in this case, imho.
From: David Mark on 8 Mar 2010 07:55 Andrea Giammarchi wrote: > On Mar 6, 11:52 am, Antony Scriven <adscri...(a)gmail.com> wrote: >> If you're checking for '=== null' 99% of the time, then >> write '=== null' 99% of the time. What is boring is >> debugging code whose intent has not been made clear by the >> author. --Antony > > I am checking to know if it is undefined or null so I use the "== > null" check 'cause I don't want to set null properties in any > prototype, it's absolutely pointless. Then why are you checking for null? That's the point. Your code is ambiguous and the next person reading it can't be expected to read your mind, so will have to investigate to determine exactly what you meant (or did not mean). > Back at the beginning, it is boring to write every time that I meant > it via code. What does that mean? > If you don't know == null means === undefined || === null it cannot be > other devs fault. That's not the point. I know what it means, but I can't guess what _you_ thought it meant. If I find, after investigation, that you were using == null when === undefined would have sufficed, I'd have to wonder what you were thinking (and I don't want to have to wonder about what you were thinking). > We are coder, not monkeys Some of us. :) > unable to understand basis of the > programming language we use on daily basis, the problem is somewhere > else in this case, imho. You have got the wrong end of the stick (again).
From: Andrea Giammarchi on 9 Mar 2010 04:11
On Mar 8, 1:55 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Then why are you checking for null? That's the point. again, to know if a variable is null or undefined since I threat both values as one, I've never had a valid reason for distinguish between null and undefined. > Your code is > ambiguous and the next person reading it can't be expected to read your > mind, so will have to investigate to determine exactly what you meant > (or did not mean). since you'll never find a === undefined in my code, I wonder wchih part is ambiguous... > What does that mean? typo, I meant every time I have to specify via *comment* that I meant it ... > That's not the point. I know what it means, but I can't guess what > _you_ thought it meant. If I find, after investigation, that you were > using == null when === undefined would have sufficed there we are ... === undefined is a disaster prone approach. Nobody should rely in a global scope variable as undefined is to understand if a variable is undefined. typeof varname === "undefined" is the only safe way, OR we can simply test against == null if we are NOT interested into undefined values. > You have got the wrong end of the stick (again). while apparently You have not get what is the problem and why ... Again, and for the last time: 1 - there is no coercion against "== null" , only a case specified by specs 2 - "== null" is true only with null or undefined, the error showed by JSLint and the privded reason (coercion) *is* *wrong* 3 - I do believe undefined is a "pointless value" on daily basis code, I rarely need to know if a value is exactly undefined ... the most common case is *double* check against null and typeof "undefined" indeed and this is a waste of time, a waste of bytes, a waste of performances ... but surely you decide how to code in a "non ambiguous way" for a case that has nothing ambiguous for its purpose, imho Regards |