Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Garrett Smith on 23 Dec 2009 02:14 David Mark wrote: > On Dec 23, 12:19 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> Changed to: >>>> * Use of == where strict equality is required >>>> Where strict equality is required, the strict equality operator must be >>>> used. >>> That goes without saying. >> It is a true statement, but not obvious to all. The recent discussion on >> Qooxdoo had an example of using == to compare two objects. I commented >> that that comparison should use strict equality. That avoids cases >> where, say, comparing a and b, a is null and b is empty string. > > Do you mean b is undefined? > Yes, of course! > null != '' Of course, I know that. Thanks for pointing it out though. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 23 Dec 2009 02:12 RobG wrote: > On Dec 22, 9:52 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [...] > I don't understand the issue here, is it specifically with the TD end > tag? Or is it more generally with end tags in HTML sent as an XHR > response? > * Not escaping ETAGO, or using concatenation to escape ETAGO. Inline script must not contain the character sequence "</" http://www.w3.org/TR/WD-script-970314 When concatenating strings of HTML in an inline script, a backslash should appear before the solidus symbol in the sequence "</", resulting in "<\/", and not - "<" + "/" -. > A suitable alternative may be to omit the closing TD tag altogether > (valid in HTML 4.01 and draft HTML 5). > > <URL: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission > > >> CSS: >> * invalid css >> * classNames that do not have semantic meaning > > While that comment is OK for class values used for CSS, it should be > noted that class names are not intended for CSS only. > True. Non-semantic class or ID lacks meaning (HTML and CSS). The same applies to ID. Instead, class and id should be meaningful, so the code is easier to understand. Bad: ..errorButton, #warningMessage Good: > > [...] >> RegularExpressions >> Be simple, but do not match the wrong thing. > > Not sure what that means. The context of a Regular Expression is is as important as what it can match. A complex regular expression is harder to understand than a simple one and so simple regular expressions are preferred. It is OK the expression can match the wrong thing, just so long as the context in which it is used precludes or handles that. // Wrong: Matches 137, 138... ARROW_KEY_EXP : /37|38|39|40/; // Right: matches only arrow keys. ARROW_KEY_EXP : /^(?:37|38|39|40)$/; // Simple: Can match the wrong thing, but that can be handled. var iso8601Exp = /^\s*([\d]{4})-(\d\d)-(\d\d)\s*$/; Trying to match leap years would be excessively complex. Instead, the date validation can be addressed where the expression is used. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 23 Dec 2009 02:15 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >> >>> Changed to: >>> * Use of == where strict equality is required >>> Where strict equality is required, the strict equality operator must be >>> used. >> >> That goes without saying. >> > > It is a true statement, but not obvious to all. The recent discussion on > Qooxdoo had an example of using == to compare two objects. I commented > that that comparison should use strict equality. That avoids cases > where, say, comparing a and b, a is null and b is empty string. Correction: where, say, comparing - a - is null and - b - is undefined. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 22 Dec 2009 19:11 Garrett Smith wrote: > Changed to: > * Use of == where strict equality is required > Where strict equality is required, the strict equality operator must be > used. That goes without saying. > The strict equality operator should always be used to compare > identity. > > Example:- > // Do not use == to compare identity. > if (element == target) { > return true; > } Define `identity'. It makes no difference whether `==' or `===' is used if both values are object references (as in "objects have identity"). To be exact, it makes no difference whether `==' or `===' is used if both values are of the same internal type, e.g., Object. That is, it makes only a little difference with regard to compatibility as `==' is slightly more compatible than `==='. > In the case of checking to see if a value can be null or undefined, I > don't have any problem with:- > > if(v == null) { > > } ACK. Then again, one seldom needs that because with a function one wants to differentiate whether an argument was not passed, whereas the value of the argument were `undefined', or whether `null' was passed. In all other cases either host objects are involved and a `typeof' test is safer, or native objects are involved and a type-converting test is more efficient. > Others do not using == to loose check. [...] Parse error. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Asen Bozhilov on 23 Dec 2009 03:32
Garrett Smith wrote: > RegularExpressions > Be simple, but do not match the wrong thing. I ever wondering about using RegExp for type checking. /^\s*\bfunction\b/.test("" + f); That will be check implementation depended string returned from f.toString(); for as function, and that checking can be falsish. e.g. var o = { toString : function() { return 'function function'; } }; window.alert(/^\s*\bfunction\b/.test("" + o)); //true |