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 22 Dec 2009 18:19 Asen Bozhilov wrote: > Dmitry A. Soshnikov wrote: > >>> Statements: >>> * Use of == where === should be used >>> if(typeof val === "undefined"){ } >> typeof returns always string, so there's no any difference using == or >> === in this case (algorithms are equivalent: word for word); == is >> less on one symbol, you can use typeof val == 'undefined'. > > Yes, here you are absolutely right. But `==' can be harmful especially > when `EqualityExpression` and `RelationalExpression` ares from > different type, because one of them will be converted to primitive > value. > Yes, Dmitry is correct, you're both right. I wasn't explicit enough, or used terminology that was open to interpretation. Changed to: * Use of == where strict equality is required Where strict equality is required, the strict equality operator must be used. The strict equality operator should always be used to compare identity. Example:- // Do not use == to compare identity. if (element == target) { return true; } 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) { } Others do not using == to loose check. JSLint will error on that, I believe. [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 23 Dec 2009 00:19 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. Same goes with unqualified assignment. >> 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'. The same unique object. As in, "if source is the target..." if(source === target) { } and not:- if(source == target) { } The strict equality tests leaves no ambiguity to the reader of the code that the intent is to check identity. There is no room for considering what happens when one operand is a different type. 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 `==='. > I think you meant "built-in" where you wrote "internal type". While it is true that comparing two native ES objects using == does not result in conversion, it still allows the possibility where when one side of the operation is not an object, then conversion will happen. It may seem unlikely to occur, but the added insurance of using === doesn't hurt. It can actually result in nanosecond performance increase in IE. For host object, == can be true while === is false. javascript: alert( self === window );// false javascript: alert( self == window ); // true [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 23 Dec 2009 00:30 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? null != ''
From: David Mark on 23 Dec 2009 00:37 On Dec 22, 10:38 pm, RobG <rg...(a)iinet.net.au> wrote: > On Dec 22, 9:52 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > > > I'm putting together a couple of documents: > > > 1) code guidelines > > 2) code review guidelines > > > The goals are to help make for better code reviews here and to help > > debate on assessing javascript code quality. > > > I'd like to start with my outline of code guidelines and get some > > feedback on it. > > > Rich Internet Application Development Code Guildelines (Draft) > > > Problems: > > > Markup: > > * Invalid HTML > > * sending XHTML as text/html > > * xml prolog (cause problems in IE) > > * javascript: pseudo protocol > > * Not escaping ETAGO. > > Replace: "</" + "script>" > > with: "<\/script>"; > > Replace: "</td>"; > > with: "<\/td>"; > > 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? No, it refers to markup in script (e.g. document.write calls). Nothing to do with the tag type. > > 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. I try to avoid that. > > [...] > > > RegularExpressions > > Be simple, but do not match the wrong thing. > > Not sure what that means. Seems overly simplified.
From: Garrett Smith on 22 Dec 2009 19:01
Asen Bozhilov wrote: > Asen Bozhilov wrote: >> Garrett Smith wrote: >>> * Boolean conversion of Host object (sometimes Error-prone) >> //Boolean conversation host object in JScript >> var xhr = new ActiveXObject('Microsoft.XMLHTTP'); >> Boolean(xhr.open); > > Garrett do you have any others example where Boolean conversion throw > Error? > No, you're right, I was mistaken. That should be replaced with something appropriate. > In my example error will be throwing from internal [[Get]] method of > `object' referred from `xhr'. > > var xhr = new ActiveXObject('Microsoft.XMLHTTP'); > try { > var a = xhr.open; > }catch(e) > { > window.alert(e); //Object doesn't support this property or method > } > > Here isn't the problem in type conversion. The problem is before that. > That example can show it own implementation of [[Get]] and [[Put]] > methods from that host object. > You're right about it not being ToBoolean. The error is from accessing the property. I had believe the error was caused by type conversion. Without doing anything with xhr.open method:- javascript: new ActiveXObject('Microsoft.XMLHTTP').open; Error: Object doesn't support this property or method. Thanks for pointing that out. | * Error-prone handling of Host objects. | Potentially disconnected nodes behave differently | javascript: void document.createElement("div").offsetParent; | Unspecified Error in IE. | Instead, use typeof to avoid undefined values or IE "unknown" types: | var div = document.createElement("div"); | isOffsetParentSafe = !/^un/.test(typeof div.offsetParent); -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |