Nó nguy hiểm như thế nào trong JavaScript, thực sự, để cho rằng undefined không bị ghi đè?

Mỗi khi bất kỳ ai đề cập đến thử nghiệm chống lại undefined, nó chỉ ra rằng đó undefinedkhông phải là một từ khóa để nó có thể được đặt thành"hello" , vì vậy bạn nên sử dụng typeof x == "undefined" thay thế. Điều này có vẻ vô lý đối với tôi. Sẽ chẳng có ai làm điều đó cả, và nếu họ làm vậy thì sẽ đủ lý do để không bao giờ sử dụng bất kỳ đoạn mã nào họ đã viết ... đúng không?

Tôi tìm thấy một ví dụ của một ai đó vô tình cài đặt undefinedđể null, và điều này đã được đưa ra như một lý do để tránh giả định rằng undefinedkhông được ghi đè. Nhưng nếu họ làm điều đó, lỗi sẽ không bị phát hiện và tôi không biết làm thế nào tốt hơn.

Trong C ++, mọi người đều biết rằng việc nói đó là hợp pháp #define true false, nhưng không ai khuyên bạn nên tránh truevà sử dụng 0 == 0thay thế. Bạn cứ cho rằng không ai đủ lớn để làm điều đó, và nếu họ làm vậy, đừng bao giờ tin tưởng mã của họ nữa.

Điều này đã bao giờ thực sự cắn ai đó ở nơi người khác được chỉ định undefined(có chủ đích) và nó phá mã của bạn hay đây là một mối đe dọa giả định hơn? Tôi sẵn sàng tận dụng cơ hội của mình để làm cho mã của tôi dễ đọc hơn một chút. Đây có phải là một ý tưởng thực sự tồi?

Để nhắc lại, tôi không yêu cầu làm thế nào để bảo vệ chống lại không xác định được chỉ định lại. Tôi đã thấy những thủ thuật đó được viết 100 lần rồi. Tôi đang hỏi rằng nó nguy hiểm như thế nào nếu không sử dụng những thủ thuật đó.

Không, tôi không bao giờ có. Điều này chủ yếu là do tôi phát triển trên các trình duyệt hiện đại, hầu hết đều tuân thủ ECMAScript 5. Tiêu chuẩn ES5 ra lệnh undefinedhiện chỉ đọc. Nếu bạn sử dụng chế độ nghiêm ngặt (bạn nên làm như vậy), một lỗi sẽ xuất hiện nếu bạn vô tình cố gắng sửa đổi nó.

undefined = 5;
alert(undefined); // still undefined

'use strict';
undefined = 5; // throws TypeError

Những gì bạn không nên làm là tạo phạm vi của riêng bạn, có thể thay đổi undefined:

(function (undefined) {
    // don't do this, because now `undefined` can be changed
    undefined = 5;
})();

Không đổi là tốt. Vẫn không cần thiết, nhưng tốt.

(function () {
    const undefined = void 0;
})();

Không có mã thích hợp sẽ làm một điều như vậy. Nhưng bạn không bao giờ có thể biết một số nhà phát triển thông minh hoặc một plugin / thư viện / tập lệnh bạn đang sử dụng đã làm gì. Mặt khác, điều đó cực kỳ khó xảy ra và các trình duyệt hiện đại sẽ không cho phép ghi đè lên undefined, vì vậy nếu bạn đang sử dụng một trình duyệt như vậy để phát triển, bạn sẽ nhanh chóng nhận ra nếu có bất kỳ mã nào cố gắng ghi đè lên nó.

Và mặc dù bạn không yêu cầu điều đó - nhiều người có thể sẽ tìm thấy câu hỏi này khi tìm kiếm undefinedvấn đề phổ biến hơn "cách bảo vệ chống lại xác định lại ", vì vậy tôi sẽ trả lời rằng:

Có một cách rất tốt để có được một trình duyệt thực sự không xác định cho undefined dù trình duyệt cũ đến đâu:

(function(undefined) {
    // your code where undefined is undefined
})();

Điều này hoạt động vì một đối số không được chỉ định luôn luôn là undefined. Bạn cũng có thể làm điều đó với một hàm chấp nhận một số đối số thực, ví dụ như thế này khi bạn đang sử dụng jQuery. Thông thường, bạn nên đảm bảo một môi trường lành mạnh theo cách này:

(function($, window, undefined) {
    // your code where undefined is undefined
})(jQuery, this);

Sau đó, bạn có thể chắc chắn rằng bên trong hàm ẩn danh đó, những điều sau là đúng:

• $ === jQuery
• window === [the global object]
• undefined === [undefined].

Tuy nhiên, lưu ý rằng đôi khi typeof x === 'undefined'thực sự cần thiết: Nếu biến xchưa bao giờ được đặt thành giá trị (trái với được đặt thành undefined), việc đọc xtheo một cách khác chẳng hạn như if(x === undefined)sẽ gây ra lỗi. Tuy nhiên, điều này không áp dụng cho các thuộc tính đối tượng, vì vậy nếu bạn biết rằng đó yluôn là một đối tượng thì if(y.x === undefined)sẽ hoàn toàn an toàn.

Có một giải pháp đơn giản cho điều đó: so sánh với void 0cái nào luôn không xác định.

Lưu ý rằng bạn nên tránh ==vì nó có thể ép buộc các giá trị. Sử dụng ===(và !==) thay thế.

Điều đó nói rằng, biến không xác định có thể được đặt do lỗi nếu ai đó viết =thay vì ==khi so sánh một cái gì đó với undefined.

Chỉ có bạn mới biết mã bạn sử dụng và do đó nó nguy hiểm như thế nào. Câu hỏi này không thể được trả lời theo cách bạn đã làm rõ mà bạn muốn nó được trả lời.

1) Tạo chính sách nhóm, không cho phép xác định lại không xác định, dành nó để sử dụng phổ biến hơn. Quét mã hiện có của bạn cho nhiệm vụ còn lại không xác định.

2) Nếu bạn không kiểm soát tất cả các tình huống, nếu mã của bạn được sử dụng bên ngoài các tình huống mà bạn hoặc chính sách của bạn kiểm soát, thì rõ ràng câu trả lời của bạn là khác. Quét mã sử dụng tập lệnh của bạn. Rất tiếc, hãy quét web để tìm số liệu thống kê về bài tập còn lại chưa xác định nếu bạn muốn, nhưng tôi nghi ngờ điều đó đã được thực hiện cho bạn, bởi vì thay vào đó, bạn chỉ cần theo đuổi câu trả lời số 1 hoặc số 3 ở đây sẽ dễ dàng hơn.

3) Và nếu câu trả lời đó không đủ tốt, có thể là do, một lần nữa, bạn yêu cầu một câu trả lời khác. Có thể bạn đang viết một thư viện phổ biến sẽ được sử dụng bên trong tường lửa của công ty và bạn không có quyền truy cập vào mã gọi. Sau đó, sử dụng một trong những câu trả lời hay khác ở đây. Lưu ý rằng thư viện jQuery phổ biến thực hành đóng gói âm thanh và bắt đầu:

(function( window, undefined ) {

Chỉ bạn mới có thể trả lời câu hỏi của mình theo cách cụ thể mà bạn tìm kiếm. Còn gì nữa để nói?

chỉnh sửa: ps nếu bạn thực sự muốn ý kiến ​​của tôi, tôi sẽ nói với bạn rằng nó không nguy hiểm chút nào. Bất cứ điều gì có khả năng gây ra lỗi (chẳng hạn như gán cho không xác định, rõ ràng là một hành vi rủi ro được ghi chép đầy đủ) đều là một khiếm khuyết. Đó là khiếm khuyết là rủi ro. Nhưng đó chỉ là trong các tình huống của tôi, nơi tôi có thể đủ khả năng để giữ quan điểm đó. Như tôi khuyên bạn nên làm, tôi đã trả lời câu hỏi cho các trường hợp sử dụng của mình.

Nó an toàn để kiểm tra chống lại không xác định. Như bạn đã đề cập. Nếu bạn nhận được một số mã ghi đè lên nó (rất có thể ứng biến), chỉ cần không sử dụng nó nữa.

Có thể nếu bạn đang tạo một thư viện để sử dụng chung, bạn có thể sử dụng một số kỹ thuật để tránh người dùng thay đổi nó. Nhưng ngay cả trong trường hợp này, đó là vấn đề của họ, không phải thư viện của bạn.

Bạn có thể sử dụng undefinedmã của mình khi viết mã cho các trình duyệt hỗ trợ ECMAScript 5.1 vì nó là bất biến theo đặc điểm ngôn ngữ .

Cũng thấy này bảng tính tương thích hoặc này caniuse ECMAScript 5 để thấy rằng tất cả các trình duyệt hiện đại (IE 9+) đã thực hiện bất biếnundefined .

Nó không nguy hiểm chút nào. Nó chỉ có thể được ghi đè khi chạy trên công cụ ES3 và nó sẽ không còn được sử dụng nữa.

Trước hết, nếu mã của bạn bị hỏng có lẽ không phải do một số nhà phát triển khác ngoài kia "đang cố gắng trở thành một kẻ xấu" như bạn nói.

Đó undefinedkhông phải là một từ khóa. Nhưng nó là một nguyên thủy cấp độ toàn cầu. Nó được dự định sử dụng như thế này (xem "không xác định" tại developer.mozilla.org ):

var x;
if (x === undefined) {
    // these statements execute
}
else {
    // these statements do not execute
}

Cách thay thế phổ biến cho điều đó (cũng từ MDN ) và theo tôi cách tốt hơn là:

// x has not been declared before
if (typeof x === 'undefined') { // evaluates to true without errors
    // these statements execute
}

if(x === undefined){ // throws a ReferenceError

}

Điều này có một vài ưu điểm, điều hiển nhiên (từ các bình luận) là nó không kích hoạt ngoại lệ khi x không được khai báo. Cũng cần lưu ý rằng MDN cũng chỉ ra rằng điều quan trọng là phải sử dụng ===over ==trong trường hợp đầu tiên vì:

var x=null;
if (x === undefined) {
    // this is probably what you meant to do
    // these lines will not execute in this case
}
else if (x == undefined) {
    // these statements will execute even though x *is* defined (as null)
}
else {
    // these statements do not execute
}

Đây là một lý do khác thường bị bỏ qua tại sao có lẽ tốt hơn là chỉ sử dụng giải pháp thay thế thứ hai trong mọi trường hợp.

Kết luận: Không sai khi viết mã theo cách đầu tiên và chắc chắn là không nguy hiểm. Đối số bạn đã thấy mà bạn sử dụng làm ví dụ chống lại nó (rằng nó có thể bị ghi đè) không phải là đối số mạnh nhất để viết mã thay thế bằng typeof. Nhưng việc sử dụng typeofmạnh hơn vì một lý do cụ thể: nó không ném ra ngoại lệ khi var của bạn không được khai báo. Nó cũng có thể được lập luận rằng sử dụng ==thay vì ===là một sai lầm phổ biến trong trường hợp nó không làm những gì bạn mong đợi. Vậy tại sao không sử dụng typeof?