Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Code Guidelines

Reply
Thread Tools

Code Guidelines

 
 
Garrett Smith
Guest
Posts: n/a
 
      12-23-2009
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/
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      12-23-2009
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$(E-Mail Removed)> (2004)
 
Reply With Quote
 
 
 
 
RobG
Guest
Posts: n/a
 
      12-23-2009
On Dec 22, 9:52 am, Garrett Smith <(E-Mail Removed)> 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?

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.ht...x-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.


[...]
> RegularExpressions
> Be simple, but do not match the wrong thing.


Not sure what that means.


--
Rob
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      12-23-2009
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/
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-23-2009
On Dec 23, 12:19*am, Garrett Smith <(E-Mail Removed)> 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 != ''
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-23-2009
On Dec 22, 10:38*pm, RobG <(E-Mail Removed)> wrote:
> On Dec 22, 9:52 am, Garrett Smith <(E-Mail Removed)> 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.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      12-23-2009
RobG wrote:
> On Dec 22, 9:52 am, Garrett Smith <(E-Mail Removed)> 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.ht...x-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/
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      12-23-2009
David Mark wrote:
> On Dec 23, 12:19 am, Garrett Smith <(E-Mail Removed)> 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/
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      12-23-2009
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/
 
Reply With Quote
 
Asen Bozhilov
Guest
Posts: n/a
 
      12-23-2009
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Code guidelines for checks ? nicolas.raoul@gmail.com Java 5 07-13-2007 04:47 PM
article - Guidelines for writing efficient C code Marco C Programming 19 04-12-2006 01:22 AM
Case Gallery rules and Guidelines Silverstrand Case Modding 0 06-20-2005 11:38 PM
Code Guidelines JIT ASP .Net 2 11-02-2004 06:57 AM
Java Code Convention Guidelines question... New Java 11 01-09-2004 07:48 PM



Advertisments