是時候開始使用JavaScript嚴格模式了
ECMAScript5將嚴格模式(strict mode)引入了Javascript中,目的是允許開發(fā)人員能夠選擇“更好”的Javascript版本,這個版本能用不同的方式處理那些普遍而又臭名昭著的錯誤。一開始的時候,我對該模式抱著懷疑的態(tài)度,因為當時在只有一款瀏覽器(Firefox)支持嚴格模式。時至今日,所有的主流瀏覽器的最新版本——包括IE10與Opera12——都支持嚴格模式。使用嚴格模式的時機已經成熟了。
它帶來了什么?
嚴格模式給Javascript的運行方式帶來了許多不同,我將它們分為了兩類:明顯的(obvious),以及微妙的(subtle)。那些微妙的改變是為了解決微妙的問題,我不打算在這里對其進行贅述。如果你對這些細節(jié)感興趣,請參考Dmitry Soshnikov的精彩文章,《ECMA-262-5 in Detail. Chapter 2. Strict Mode》。我對介紹明顯的變化更感興趣:它們是你開始使用嚴格模式之前所必須了解的,也可能給你帶來最多好處。
在開始介紹特殊特性之前,你需要記住,嚴格模式的目標之一是允許更快地調試錯誤。幫助開發(fā)者調試的最佳途徑是當確定的問題發(fā)生時拋出相應的錯誤(throw errors when certain patterns occur),而不是悄無聲息地失敗或者表現(xiàn)出奇怪的行為(這正是如今不在嚴格模式下的Javascript做的)。嚴格模式下的代碼拋出更多的錯誤信息,這是好事,因為它能幫助開發(fā)者很快注意到一些必須立即解決的問題。
去除with語句(Eliminates with)
首先,嚴格模式去除了with語句。當with語句出現(xiàn)在嚴格模式中時,它會被認為是非法的Javascript語句并拋出語法錯誤。所以,使用嚴格模式的第一步就是確保你沒有在使用with。
- // 在嚴格模式中將導致語法錯誤
- with (location) {
- alert(href);
- }
防止意外的全局變量(Prevents accidental globals)
第二點是,變量在賦值之前必須聲明。在非嚴格模式下,給一個未聲明的變量賦值將自動生成一個該名字的全局變量。這是Javascript中最普遍的錯誤之一。嚴格模式中,這樣做將拋出一個錯誤。
- // 嚴格模式中拋出一個錯誤
- (function() {
- someUndeclaredVar = "foo";
- }());
取消this值的強制轉換(Eliminates this coercion)
另一個重要的變化是,當this值為null或undefined時,不會再將其強制轉換為全局對象。也就是說,this保留了它的原始值,也因此可能會導致一些依賴于強制轉換的代碼發(fā)生錯誤。例如:
- window.color = "red";
- function sayColor() {
- // 嚴格模式下,this不會指向window
- alert(this.color);
- }
- // 以下兩種情況,在嚴格模式下都拋出錯誤
- sayColor();
- sayColor.call(null);
根本而言,this值必須賦值,否則將保留undefined值。這意味著調用構造函數(shù)時若漏掉了new關鍵字也會導致錯誤:
- function Person(name) {
- this.name = name;
- }
- // 嚴格模式下導致錯誤
- var me = Person("Nicholas");
在這段代碼里,調用Person構造函數(shù)時缺少了new關鍵字,此時this值為undefined。由于你不能給undefined添加屬性,這段代碼拋出了一個錯誤。在非嚴格模式下,this會強制轉換為全局對象,因此name屬性能夠被正確賦值為全局變量。
拒絕重復(No duplicates)
當你做了大量的編碼的時候,你很容易在對象中定義了重復的屬性或者給函數(shù)定義了重復的參數(shù)名。嚴格模式下,這兩種情況都會導致錯誤的發(fā)生:
- // 嚴格模式下錯誤 - 重復參數(shù)
- function doSomething(value1, value2, value1) {
- //code
- }
- // 嚴格模式下錯誤 - 重復屬性
- var object = {
- foo: "bar",
- foo: "baz"
- };
這兩者都是語法錯誤,在代碼執(zhí)行之前將拋出錯誤。
更安全的eval()(Safer eval())
eval()沒有被移除,但它在嚴格模式下發(fā)生了一些變化。最大的改變是:在eval()語句中聲明的變量以及函數(shù)不會在包含域中創(chuàng)建。例如:
- (function() {
- eval("var x = 10;");
- // 非嚴格模式下,x為10
- // 嚴格模式下,x沒有聲明,拋出一個錯誤
- alert(x);
- }());
任意由eval()創(chuàng)建的變量或函數(shù)仍呆在eval()里。然而,你可以通過從eval()中返回一個值的方式實現(xiàn)值的傳遞:
- (function() {
- var result = eval("var x = 10, y = 20; x + y");
- // 嚴格模式與非嚴格模式下都能正常工作(得到30)
- alert(result);
- }());
不可改變引發(fā)的錯誤(Errors for immutables)
ECMAScript 5 同時引入了修改屬性特征的能力,例如設置一個屬性為只讀或者凍結整個對象的結構(freezing an entire object’s structure)。在非嚴格模式下,試圖修改一個不可變的屬性時將悄無聲息地失敗。你可能在使用一些原生APIs的時候已經遇到這類問題。嚴格模式將保證無論你在何時試圖使用一種不被允許的方式修改一個對象或對象的屬性時拋出錯誤。
- var person = {};
- Object.defineProperty(person, "name" {
- writable: false,
- value: "Nicholas"
- });
- // 非嚴格模式下將悄無聲息地失敗,嚴格模式則拋出錯誤
- person.name = "John";
這個例子中,name屬性被設置為只讀。在非嚴格模式下,對name的賦值將悄無聲息地失敗;而在嚴格模式下,一個錯誤將被拋出。
注:如果你在使用ECMAScript屬性能力(the ECMAScript attribute capabilities),我強烈推薦你開啟嚴格模式。如果你在改變對象的可變性(mutability of objects),你將遇到一堆錯誤,而它們在非嚴格模式下將被安靜地帶過。
該如何使用它?
在現(xiàn)代瀏覽器中很容易啟用嚴格模式,只需添加下面一條語句:
- "use strict";
雖然這看起來只是一個沒有賦值給變量的字符串,但它確實地指示了Javascript引擎切換為嚴格模式(那些不支持嚴格模式的瀏覽器只是簡單地讀取了這個字符串然后繼續(xù)像平常一樣運行)。你可以在全局或函數(shù)中使用它。話雖這么說,你永遠不應該在全局中使用它。全局地使用這條指示,意味著同個文件下的所有代碼都在嚴格模式下運行。
- // 別這么做
- "use strict";
- function doSomething() {
- // 這將在嚴格模式下運行
- }
- function doSomethingElse() {
- // 這也是
- }
這看起來似乎不是個大問題,但在我們這個不同腳本堆積在一起的世界里(our world of aggressive script concatenation)將導致大麻煩。只要有一份腳本全局地包含這條指令,其它串聯(lián)的腳本也將在嚴格模式下運行(可能引發(fā)一些你從沒預想到的錯誤)。
因此,最好只在函數(shù)內使用嚴格模式,例如:
- function doSomething() {
- "use strict";
- // 嚴格模式下運行
- }
- function doSomethingElse() {
- // 非嚴格模式下運行
- }
如果你想講嚴格模式應用于多個函數(shù),可以使用如下模式( immediately-invoked function expression (IIFE)):
- (function() {
- "use strict";
- function doSomething() {
- // this runs in strict mode
- }
- function doSomethingElse() {
- // so does this
- }
- }());
結論
我強烈建議每一個人都開始使用嚴格模式。現(xiàn)在已經有足夠多的瀏覽器支持該模式,它將把你從藏身代碼的錯誤中拯救出來。你需要確保你沒有全局地包含啟用指令,但可以頻繁地使用IIFEs給任意多的代碼應用嚴格模式。一開始,你將碰到從沒遇過的錯誤——這是很正常的。切換到嚴格模式后,你需要做足夠多的測試來保證你已hold住你的代碼。一定不能只是將“use strict”扔進你的代碼然后就假設不會有錯誤發(fā)生。至少的至少,你該開始使用這個異常有用的語言特性來寫更好的代碼了。
原文:http://zhoujunmiao.com/?p=292
【編輯推薦】