Java Script Coding Standard

JavaScript is a simple ObjectFunctional ProgrammingLanguage. It was originally designed as a ScriptingLanguage for web developement with many of the idioms of the SelfLanguage and the syntax of the CeeLanguage (CeeSyntax). This coding standard covers the latest standard called EcmaScript 3 that features among others:

Although these features makes JavaScript very flexible and easy to learn, programmers inexperienced with these paradigms may have difficulty adapting. It is not the JavaLanguage; although, they share some concepts (due to an early partnership between SunMicrosystems and NetScape). Nor is it the LispLanguage despite many other simularities between their individual language philosophies. JavaScript also isn't a perfect language and several JavaScriptFlaws make complex designs difficult.

Therefore developing and complying with good coding standards makes coding in JavaScript easier, faster, and more fun.

While I tend to agree with this, I think a functional approach in JavaScript can work pretty well... Also, generic algorithms may be very powerful... -- DavidDeLis

FirstClassFunctions and LexicalClosures are orthorgonal to class-based design, and they may be used together with the traditional ObjectOriented approach. At least, I don't see them as direct competitors. -- JimmyCerra

Also I've discovered, to my dismay, that InternetExplorer doesn't allow you to add methods to its core DOM classes - which pretty much kills the idea of using the receiver paradigm (i.e., class-based approach). See http://www.codingforums.com/showthread.php?threadid=2948 -- RandyStafford

Wouldn't a DecoratorPattern work for this? Seems like it's a common approach to such situations. -- TomStambaugh

I wish I could use the DecoratorPattern, Tom. The problem is the web browser won't instantiate my decorators when loading a page. Instead it will instantiate its own core DOM classes - which precludes code like "document.someForm.someFunctionOfMine()". I gave up and reverted to a procedural approach, passing would-be receivers as the first arguments to functions declared on the global object. -- RandyStafford

(I may be late to the conversation.) RandyStafford, why can't you still use a decorator: "f = new Decorator(document.someForm); f.someFunctionOfMine();"? -- Jimmy Cerra 

/*-------------------------------------------------------------------------
 * Gui framework classes for the Web Client are stored in this file.
 *
 * DEPENDENCIES
 *  - Data.js
 *  - Utils.js
 *-------------------------------------------------------------------------/
The first line gives a brief description of the file's contents and the DEPENDENCIES give the files that should be imported while using these classes. Why explicitly list dependencies? Don't JavaScriptIde's provide this kind of support?

I'll add: why hinting the dependencies? The explicit list of load()s, import()s or include()s should be explicit enough... -- DavidDeLis

For library-type files, I'm all for listing the dependencies: it has to be documented somehow, and trying to import the files without the luxury of an import statement requires assumptions about the host - it may not even be possible with some hosts. -- DanielBrockman

Don't JavaScriptIde's provide this kind of support?

What "JavaScriptIde's"? Are there any? Are any of them any good? -- TomStambaugh 

/**
 * Utility method for getting product.
 *
 * @param int a A value.
 * @param int b Another value.
 */
function Utils_product(a, b) {
return a*b;
}
Here, you have noticed that both the parameters have type associated with it. The following point elaborates on it. Good idea if we find a tool similar to javadoc. Also, the type information may be irrelevant for our function... -- DavidDeLis

Tools such as jsdoc-toolkit (http://jsdoctoolkit.org/) provide functionality similar to javadoc. -- NathanLloydSmith?

I like do the same thing, but in comments: 

function Utils_product( /*int*/ a, /*int*/ b ) {
It looks a little more like Java code this way, and brings the type closer to the variable. -- DanielCohen? JavaScriptIsNotJava?

JavaScript does have types, they are just dynamic, this is far more flexible than static types as all calls are polymorphic.

This is a bad idea and completely defeats the purpose of OO and shows a huge misunderstanding of what OO is really about. Just have two different classes, one to implement IE, one to implement Netscape, both with the same interface and dynamically switch them at runtime. Want to add Opera later, just write another.

[I agree it is a bad idea. A better idea is to use a StrategyPattern together with lambda functions. For example:] 

var fn = isIE() ? function() {
// IE stuff
} : isMoz() ? function() {
// IE stuff
} : isOpera() ? function() {
// Opera stuff
} : function() {
// Default stuff
};
This is still a bad idea, and it still misses the entire point of OO. OO exists so that you don't have to do the switching, let the language do it for you and take advantage of polymorphism. The above code shows a complete lack of understanding of polymorphism and how it should be used. Have an Opera class, an IE class, a Mozilla class, all sharing the same interface, and decide once at startup which browser you're using, and just use that class; that's the StrategyPattern. The above is not a strategy pattern, it's a case statement in disguise and it's bad code. (CaseStatementsConsideredHarmful)

I've seen this pattern in the wild (real world); it works well. Another variant: 

var strategy = {
ie: function() {this.name="MSIE";},
ns: function() {this.name="Netscape";}
};


strategy.op = function() {this.name="Opera";};


var obj = new strategy[getClientUserAgentId()]();
window.alert(obj.name);
-- Jimmy Cerra

It's a good list of recommendations, and the intention and idea are excellent. But I can feel a certain tendency towards Java. While JavaLanguage is a powerul tool, and JavaScript certainly has 'java' in the name, it's not java, just a victim of marketroids. We should try to find more idiomatic recommendations. The differences between both languages deserve some credit, so to say. Just my thoughts, though... I will try to think on more suggestions. Thank you -- DavidDeLis

It appears to me that JavaScript is much closer to SmalltalkLanguage than to JavaLanguage or CeeLanguage, specifically with respect to DynamicTyping, name scoping, and compilation issues. I therefore suspect that the naming standards and other conventions developed over the 20+ year experience of the SmalltalkLanguage community will serve better than the Java conventions. -- TomStambaugh

CategoryJavaScript

EditText of this page (last edited November 5, 2010) or FindPage with title or text search