這篇文章主要摘自阮大大的文章了解,說明的很透徹。于是我分享出來。
一、為什麼Javascript有設計缺陷?
這裡有三個客觀原因,導緻Javascript的設計不夠完善。
1. 設計階段過于倉促
Javascript的設計,其實隻用了十天。而且,設計師是為了向公司交差,本人并不願意這樣設計(參見《Javascript誕生記》)。
另一方面,這種語言的設計初衷,是為了解決一些簡單的網頁互動(比如,檢查"使用者名"是否填寫),并沒有考慮複雜應用的需要。設計者做夢也想不到,Javascript将來可以寫出像Gmail這種極其龐大複雜的網頁。
2. 沒有先例
Javascript同時結合了函數式程式設計和面向對象程式設計的特點,這很可能是曆史上的第一例。而且直到今天為止,Javascript仍然是世界上唯一使用Prototype繼承模型的主要語言。這使得它沒有設計先例可以參考。
3. 過早的标準化
Javascript的發展非常快,根本沒有時間調整設計。
1995年5月,設計方案定稿;10月,解釋器開發成功;12月,向市場推出,立刻被廣泛接受,全世界的使用者大量使用。Javascript缺乏一個從小到大、慢慢積累使用者的過程,而是連續的爆炸式擴散增長。大量的既成網頁和業餘網頁設計者的參與,使得調整語言規格困難重重。
更糟的是,Javascript的規格還沒來及調整,就固化了。
1996年8月,微軟公司強勢介入,宣布推出自己的腳本語言Jscript;11月,為了壓制微軟,網景公司決定申請Javascript的國際标準;1997年6月,第一個國際标準ECMA-262正式頒布。
也就是說,Javascript推出一年半之後,國際标準就問世了。設計缺陷還沒有充分暴露就成了标準。相比之下,C語言問世将近20年之後,國際标準才頒布。
二、Javascript的10個設計缺陷
1. 不适合開發大型程式
Javascript沒有名稱空間(namespace),很難子產品化;沒有如何将代碼分布在多個檔案的規範;允許同名函數的重複定義,後面的定義可以覆寫前面的定義,很不利于子產品化加載。
2. 非常小的标準庫
Javascript提供的标準函數庫非常小,隻能完成一些基本操作,很多功能都不具備。
3. null和undefined
null屬于對象(object)的一種,意思是該對象為空;undefined則是一種資料類型,表示未定義。
typeof null; // object
typeof undefined; // undefined
兩者非常容易混淆,但是含義完全不同。
var foo;
alert(foo == null); // true
alert(foo == undefined); // true
alert(foo === null); // false
alert(foo === undefined); // true
在程式設計實踐中,null幾乎沒用,根本不應該設計它。
4. 全局變量難以控制
Javascript的全局變量,在所有子產品中都是可見的;任何一個函數内部都可以生成全局變量,這大大加劇了程式的複雜性。
a = 1;
(function(){
b=2;
alert(a);
})(); // 1
alert(b); //2
5. 自動插入行尾分号
Javascript的所有語句,都必須以分号結尾。但是,如果你忘記加分号,解釋器并不報錯,而是為你自動加上分号。有時候,這會導緻一些難以發現的錯誤。
比如,下面這個函數根本無法達到預期的結果,傳回值不是一個對象,而是undefined。
function(){
return
{
i=1
};
}
原因是解釋器自動在return語句後面加上了分号。
function(){
return;
{
i=1
};
}
6. 加号運算符
+号作為運算符,有兩個含義,可以表示數字與數字的和,也可以表示字元與字元的連接配接。
alert(1+10); // 11
alert("1"+"10"); // 110
如果一個操作項是字元,另一個操作項是數字,則數字自動轉化為字元。
alert(1+"10"); // 110
alert("10"+1); // 101
這樣的設計,不必要地加劇了運算的複雜性,完全可以另行設定一個字元連接配接的運算符。
7. NaN
NaN是一種數字,表示超出了解釋器的極限。它有一些很奇怪的特性:
NaN === NaN; //false
NaN !== NaN; //true
alert( 1 + NaN ); // NaN
與其設計NaN,不如解釋器直接報錯,反而有利于簡化程式。
8. 數組和對象的區分
由于Javascript的數組也屬于對象(object),是以要區分一個對象到底是不是數組,相當麻煩。Douglas Crockford的代碼是這樣的:
if ( arr &&
typeof arr === 'object' &&
typeof arr.length === 'number' &&
!arr.propertyIsEnumerable('length')){
alert("arr is an array");
}
9. == 和 ===
==用來判斷兩個值是否相等。當兩個值類型不同時,會發生自動轉換,得到的結果非常不符合直覺。
"" == "0" // false
0 == "" // true
0 == "0" // true
false == "false" // false
false == "0" // true
false == undefined // false
false == null // false
null == undefined // true
" \t\r\n" == 0 // true
是以,推薦任何時候都使用"==="(精确判斷)比較符。
10. 基本類型的包裝對象
Javascript有三種基本資料類型:字元串、數字和布爾值。它們都有相應的建構函數,可以生成字元串對象、數字對象和布爾值對象。
new Boolean(false);
new Number(1234);
new String("Hello World");
與基本資料類型對應的對象類型,作用很小,造成的混淆卻很大。
alert( typeof 1234); // number
alert( typeof new Number(1234)); // object
關于Javascript的更多怪異行為,請參見Javascript Garden和wtfjs.com。
三、如何看待Javascript的設計缺陷?
既然Javascript有缺陷,數量還不少,那麼它是不是一種很糟糕的語言?有沒有前途?
回答是Javascript并不算糟糕,相反它的程式設計能力很強大,前途很光明。
首先,如果遵守良好的程式設計規範,加上第三方函數庫的幫助,Javascript的這些缺陷大部分可以回避。
其次,Javascript目前是網頁程式設計的唯一語言,隻要網際網路繼續發展,它就必然一起發展。目前,許多新項目大大擴充了它的用途,node.js使得Javascript可以用于後端的伺服器程式設計,coffeeScript使你可以用python和ruby的文法,撰寫Javascript。
最後,隻要釋出新版本的語言标準(比如 ECMAscript 5),就可以彌補這些設計缺陷。當然,标準的釋出和标準的實作是兩回事,上述的很多缺陷也許會一直伴随到Javascript存在的最後一天。
(完)