Việc sử dụng == trong JavaScript có bao giờ có ý nghĩa không?

Trong JavaScript, phần tốt , Douglas Crockford đã viết:

JavaScript có hai bộ toán tử đẳng thức: ===và !==, cặp song sinh xấu xa của chúng ==và !=. Những người tốt làm việc theo cách bạn mong đợi. Nếu hai toán hạng cùng loại và có cùng giá trị, thì ===tạo truevà !==sản xuất false. Cặp song sinh độc ác làm điều đúng khi các toán hạng cùng loại, nhưng nếu chúng thuộc các loại khác nhau, chúng cố gắng ép buộc các giá trị. Các quy tắc mà họ làm điều đó là phức tạp và không đáng nhớ. Đây là một số trường hợp thú vị:

'' == '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

Sự thiếu minh bạch là đáng báo động. Lời khuyên của tôi là đừng bao giờ sử dụng cặp song sinh độc ác. Thay vào đó, luôn luôn sử dụng ===và !==. Tất cả các so sánh chỉ hiển thị sản xuất falsevới các ===nhà điều hành.

Với sự quan sát không rõ ràng này, có khi nào sử dụng ==có thể thực sự phù hợp?

Tôi sẽ tranh luận về ==

Douglas Crockford mà bạn đã trích dẫn được biết đến với nhiều ý kiến ​​và thường rất hữu ích của mình. Trong khi tôi với Crockford trong trường hợp cụ thể này, điều đáng nói là nó không phải là ý kiến duy nhất . Có những người khác như người sáng tạo ngôn ngữ Brendan Eich, người không thấy vấn đề lớn với ==. Đối số đi một chút như sau:

JavaScript là một ngôn ngữ được đánh máy theo hành vi. Mọi thứ được xử lý dựa trên những gì họ có thể làm và không phải loại thực tế của họ. Đây là lý do tại sao bạn có thể gọi .mapphương thức của một mảng trên NodeList hoặc trên bộ lựa chọn jQuery. Đó cũng là lý do tại sao bạn có thể làm 3 - "5"và lấy lại một cái gì đó có ý nghĩa - bởi vì "5" có thể hoạt động như một con số.

Khi bạn thực hiện một ==đẳng thức, bạn đang so sánh nội dung của một biến chứ không phải kiểu của nó . Dưới đây là một số trường hợp hữu ích:

• Đọc một số từ người dùng - đọc .valuephần tử đầu vào trong DOM? Không vấn đề gì! Bạn không phải bắt đầu truyền nó hoặc lo lắng về loại của nó - bạn có thể ==lấy ngay số đó và lấy lại thứ gì đó có ý nghĩa.
• Cần kiểm tra "sự tồn tại" của một biến được khai báo? - bạn có thể làm == nullđiều đó vì nullđại diện cho hành vi không có gì ở đó và không xác định cũng không có gì ở đó.
• Cần kiểm tra nếu bạn có đầu vào có ý nghĩa từ người dùng? - kiểm tra xem đầu vào có sai với ==đối số hay không, nó sẽ xử lý các trường hợp người dùng không nhập gì hoặc chỉ khoảng trắng cho bạn, đây có thể là thứ bạn cần.

Hãy xem xét các ví dụ của Crockford và giải thích chúng theo hành vi:

'' == '0'           // got input from user vs. didn't get input - so false
0 == ''             // number representing empty and string representing empty - so true
0 == '0'            // these both behave as the number 0 when added to numbers - so true    
false == 'false'    // false vs got input from user which is truthy - so false
false == '0'        // both can substitute for 0 as numbers - so again true

false == undefined  // having nothing is not the same as having a false value - so false
false == null       // having empty is not the same as having a false value - so false
null == undefined   // both don't represent a value - so true

' \t\r\n ' == 0     // didn't get meaningful input from user vs falsey number - true 

Về cơ bản, ==được thiết kế để hoạt động dựa trên cách người nguyên thủy hành xử trong JavaScript không dựa trên những gì họ đang có . Mặc dù cá nhân tôi không đồng ý với quan điểm này, nhưng chắc chắn có công trong việc thực hiện nó - đặc biệt nếu bạn áp dụng mô hình xử lý các loại dựa trên ngôn ngữ hành vi trên toàn hành vi.

^{* một số có thể thích cách gõ cấu trúc tên phổ biến hơn nhưng có một sự khác biệt - không thực sự quan tâm đến việc thảo luận về sự khác biệt ở đây.}

Hóa ra jQuery sử dụng cấu trúc

if (someObj == null) {
  // do something
}

rộng rãi, như một cách viết tắt cho mã tương đương:

if ((someObj === undefined) || (someObj === null))  {
  // do something
}

Đây là kết quả của Đặc tả ngôn ngữ ECMAScript § 11.9.3, Thuật toán so sánh đẳng thức trừu tượng , trong đó nêu rõ, trong số những điều khác,

1.  If Type(x) is the same as Type(y), then  
    a.  If Type(x) is Undefined, return true.  
    b.  If Type(x) is Null, return true.

và

2.  If x is null and y is undefined, return true.
3.  If x is undefined and y is null, return true.

Kỹ thuật đặc biệt này đủ phổ biến để JSHint có một cờ được thiết kế riêng cho nó.

Kiểm tra giá trị cho nullhoặc undefinedlà một điều, như đã được giải thích rất nhiều.

Có một điều nữa, nơi ==tỏa sáng:

Bạn có thể định nghĩa so sánh >=như vậy (mọi người thường bắt đầu từ >nhưng tôi thấy điều này thanh lịch hơn):

• a > b <=> a >= b && !(b >= a)
• a == b <=> a >= b && b >= a
• a < bvà a <= bđược để lại như một bài tập cho người đọc.

Như chúng ta biết, trong JavaScript "3" >= 3và "3" <= 3, từ đó bạn nhận được 3 == "3". Bạn có thể đưa ra quan điểm rằng đó là một ý tưởng khủng khiếp để cho phép thực hiện so sánh giữa các chuỗi và số bằng cách phân tích chuỗi. Nhưng cho rằng đây là cách nó hoạt động, ==hoàn toàn là cách chính xác để thực hiện toán tử mối quan hệ đó.

Vì vậy, điều thực sự tốt ==là nó phù hợp với tất cả các mối quan hệ khác. Nói cách khác, nếu bạn viết điều này:

function compare(a, b) {
  if (a > b) return 1;
  if (a < b) return -1;
  return 0;
}

Bạn đang ngầm sử dụng ==.

Bây giờ với câu hỏi khá liên quan về: Có phải là một lựa chọn tồi để thực hiện so sánh số và chuỗi theo cách nó được thực hiện không? Nhìn thấy trong sự cô lập, có vẻ như một điều khá ngu ngốc để làm. Nhưng trong bối cảnh các phần khác của JavaScript và DOM, nó tương đối thực dụng, xem xét rằng:

• các thuộc tính luôn là các chuỗi
• các khóa luôn là các chuỗi (trường hợp sử dụng mà bạn sử dụng Objectđể có một bản đồ thưa thớt từ ints đến các giá trị)
• giá trị điều khiển đầu vào và biểu mẫu của người dùng luôn là các chuỗi (ngay cả khi nguồn khớp input[type=number])

Vì nhiều lý do, việc tạo ra các chuỗi hoạt động giống như số khi cần thiết là điều hợp lý. Và giả sử rằng so sánh chuỗi và nối chuỗi có các toán tử khác nhau (ví dụ ::để nối và phương pháp so sánh (trong đó bạn có thể sử dụng tất cả các loại tham số liên quan đến độ nhạy trường hợp và không)), thực tế điều này sẽ ít gây rối hơn. Nhưng quá tải toán tử này có lẽ thực tế là "Java" trong "JavaScript" xuất phát từ đâu;)

Là một nhà toán học chuyên nghiệp, tôi thấy trong toán tử mẫu của Javscript == (còn gọi là "so sánh trừu tượng", "bình đẳng lỏng lẻo" ) một nỗ lực xây dựng mối quan hệ tương đương giữa các thực thể, bao gồm tính phản xạ , đối xứng và bắc cầu . Thật không may, hai trong số ba thuộc tính cơ bản này thất bại:

==không phải là phản xạ :

A == A có thể sai, vd

NaN == NaN // false

==không mang tính bắc cầu :

A == Bvà B == Ccùng nhau không ngụ ý A == C, ví dụ

'1' == 1 // true
1 == '01' // true
'1' == '01' // false

Chỉ có tài sản đối xứng tồn tại:

A == Bngụ ý B == A, vi phạm có lẽ là không thể tưởng tượng trong mọi trường hợp và sẽ dẫn đến nổi loạn nghiêm trọng;)

Tại sao quan hệ tương đương có vấn đề?

Bởi vì đó là loại quan hệ phổ biến và phổ biến nhất, được hỗ trợ bởi nhiều ví dụ và ứng dụng. Ứng dụng quan trọng nhất là phân rã các thực thể thành các lớp tương đương , bản thân nó là một cách hiểu rất thuận tiện và trực quan để hiểu các mối quan hệ. Và việc không tương đương dẫn đến việc thiếu các lớp tương đương, điều này dẫn đến việc thiếu trực giác và sự phức tạp không cần thiết được biết đến.

Tại sao nó là một ý tưởng khủng khiếp để viết ==cho một mối quan hệ không tương đương?

Bởi vì nó phá vỡ sự quen thuộc và trực giác của chúng tôi, vì theo nghĩa đen, bất kỳ mối quan hệ thú vị nào về sự tương đồng, bình đẳng, đồng đẳng, đẳng cấu, bản sắc, v.v ... là một sự tương đương.

Chuyển đổi loại

Thay vì dựa vào sự tương đương trực quan, JavaScript giới thiệu chuyển đổi loại:

Toán tử đẳng thức chuyển đổi các toán hạng nếu chúng không cùng loại, sau đó áp dụng so sánh nghiêm ngặt.

Nhưng chuyển đổi loại được định nghĩa như thế nào? Thông qua một bộ quy tắc phức tạp với nhiều ngoại lệ?

Cố gắng xây dựng mối quan hệ tương đương

Booleans. Rõ ràng truevà falsekhông giống nhau và nên ở trong các lớp khác nhau.

Số. May mắn thay, sự bằng nhau của các số đã được xác định rõ, trong đó hai số khác nhau không bao giờ trong cùng một lớp tương đương. Trong toán học, đó là. Trong JavaScript, khái niệm số có phần bị biến dạng thông qua sự hiện diện của kỳ lạ hơn -0, Infinityvà -Infinity. Trực giác toán học của chúng tôi chỉ ra rằng 0và -0nên ở trong cùng một lớp (thực tế -0 === 0là vậy true), trong khi mỗi trường hợp là một lớp riêng biệt.

Số và Booleans. Cho các lớp số, chúng ta đặt booleans ở đâu? falsetrở nên tương tự 0, trong khi truetrở nên tương tự 1nhưng không có số khác:

true == 1 // true
true == 2 // false

Có logic nào ở đây để đặt truecùng với 1? Phải thừa nhận 1là khác biệt, nhưng cũng vậy -1. Cá nhân tôi không thấy bất kỳ lý do để chuyển đổi truesang 1.

Và nó thậm chí còn tồi tệ hơn:

true + 2 // 3
true - 1 // 0

Vì vậy, truethực sự được chuyển đổi thành 1một trong số tất cả các số! Nó có logic không? Có trực quan không? Câu trả lời còn lại là bài tập;)

Nhưng những gì về điều này:

1 && true // true
2 && true // true

Boolean chỉ xcó x && truecon người truelà x = true. Điều đó chứng tỏ rằng cả hai 1và 2(và bất kỳ số nào khác ngoài 0) chuyển đổi thành true! Những gì nó thấy là chuyển đổi của chúng tôi không khác tính chất quan trọng - là song ánh . Có nghĩa là hai thực thể khác nhau có thể chuyển đổi thành cùng một. Mà, tự nó, không phải là một vấn đề lớn. Vấn đề lớn nảy sinh khi chúng tôi sử dụng chuyển đổi này để mô tả mối quan hệ "giống nhau" hoặc "bình đẳng lỏng lẻo" của bất cứ điều gì chúng tôi muốn gọi nó. Nhưng có một điều rõ ràng - nó sẽ không phải là một mối quan hệ tương đương và nó sẽ không được mô tả bằng trực giác thông qua các lớp tương đương.

Nhưng chúng ta có thể làm tốt hơn không?

Ít nhất là về mặt toán học - chắc chắn là có! Một mối quan hệ tương đương đơn giản giữa booleans và số có thể được xây dựng chỉ với falsevà 0nằm trong cùng một lớp. Vì vậy, false == 0sẽ là bình đẳng lỏng lẻo không tầm thường.

Còn dây thì sao?

Chúng ta có thể cắt các chuỗi từ khoảng trắng ở đầu và cuối để chuyển đổi thành số, ngoài ra chúng ta có thể bỏ qua các số 0 ở phía trước:

'   000 ' == 0 // true
'   0010 ' == 10 // true

Vì vậy, chúng ta có một quy tắc đơn giản cho một chuỗi - cắt bớt các khoảng trắng và số 0 ở phía trước. Hoặc là chúng tôi nhận được một số hoặc chuỗi trống, trong trường hợp đó chúng tôi chuyển đổi thành số đó hoặc bằng không. Hoặc chúng tôi không nhận được một số, trong trường hợp đó chúng tôi không chuyển đổi và do đó không có mối quan hệ mới.

Bằng cách này, chúng tôi thực sự có thể có được một mối quan hệ tương đương hoàn hảo trên tổng số booleans, số và chuỗi! Ngoại trừ việc ... các nhà thiết kế JavaScript rõ ràng có ý kiến ​​khác:

' ' == '' // false

Vì vậy, hai chuỗi mà cả hai chuyển đổi thành 0đột nhiên không giống nhau! Tại sao hay tại sao? Theo quy tắc, các chuỗi là lỏng lẻo chính xác khi chúng hoàn toàn bằng nhau! Không chỉ quy tắc này phá vỡ tính siêu việt như chúng ta thấy, mà còn là dư thừa! Điểm tạo ra một toán tử khác ==để làm cho nó hoàn toàn giống với toán tử kia là ===gì?

Phần kết luận

Toán tử đẳng thức lỏng lẻo ==có thể rất hữu ích nếu nó tuân theo một số định luật toán học cơ bản. Nhưng thật đáng buồn là nó không hữu dụng.

Có, tôi đã chạy qua một trường hợp sử dụng cho nó, cụ thể là khi bạn so sánh một khóa với một giá trị số:

for (var key in obj) {
    var some_number = foo(key, obj[key]);  // or whatever -- this is just an example
    if (key == some_number) {
        blah();
    }
}

Tôi nghĩ rằng sẽ rất tự nhiên hơn khi thực hiện so sánh key == some_numberhơn là Number(key) === some_numberhoặc như key === String(some_number).

Tôi đã chạy qua một ứng dụng khá hữu ích ngày hôm nay. Nếu bạn muốn so sánh số đệm, như 01với số nguyên bình thường, ==chỉ hoạt động tốt. Ví dụ:

'01' == 1 // true
'02' == 1 // false

Nó giúp bạn tiết kiệm 0 và chuyển đổi thành một số nguyên.

Tôi biết đây là một câu trả lời muộn, nhưng dường như có một số nhầm lẫn có thể xảy ra nullvà undefined, IMHO là thứ tạo ra ==cái ác, hơn nữa là sự thiếu tính xuyên suốt, đủ tệ. Xem xét:

p1.supervisor = 'Alice';
p2.supervisor = 'None';
p3.supervisor = null;
p4.supervisor = undefined;

Chúng có nghĩa là gì?

• p1 có một giám sát viên tên là "Alice."
• p2 có một giám sát viên có tên là "Không có."
• p3một cách rõ ràng, dứt khoát, không có người giám sát .
• p4có thể có hoặc có người giám sát Chúng tôi không biết, chúng tôi không quan tâm, chúng tôi không cần phải biết (vấn đề riêng tư?), Vì đó không phải là việc của chúng tôi.

Khi bạn sử dụng, ==bạn đang bị xáo trộn nullvà undefinedđiều này hoàn toàn không đúng. Hai thuật ngữ có nghĩa là những điều hoàn toàn khác nhau! Nói rằng tôi không có người giám sát chỉ vì tôi từ chối nói với bạn rằng người giám sát của tôi là sai!

Tôi hiểu rằng có những lập trình viên không quan tâm đến sự khác biệt này giữa nullvà undefinedhoặc chọn sử dụng các thuật ngữ này một cách khác nhau. Và nếu thế giới của bạn không sử dụng nullvà undefinedchính xác, hoặc bạn muốn đưa ra giải thích của riêng bạn cho các điều khoản này, thì hãy là như vậy. Tôi không nghĩ rằng đó là một ý tưởng tốt mặc dù.

Bằng cách này, tôi không có vấn đề với nullvà undefinedcả hai đều là giả! Hoàn toàn ổn khi nói

if (p.supervisor) { ... }

và sau đó nullvà undefinedsẽ làm cho mã xử lý người giám sát bị bỏ qua. Điều đó là chính xác, bởi vì chúng tôi không biết hoặc không có người giám sát. Tất cả đều tốt. Nhưng hai tình huống không bằng nhau . Đây là lý do tại sao ==là sai. Một lần nữa, mọi thứ có thể là sai lệch và được sử dụng theo nghĩa gõ vịt, rất phù hợp với các ngôn ngữ động. Đó là JavaScript, Pythonic, Rubyish, v.v. Nhưng một lần nữa, những thứ này KHÔNG bằng nhau.

Và đừng làm cho tôi bắt đầu vào phi transitivity: "0x16" == 10, 10 == "10"nhưng không phải "10" == "0x16". Có, JavaScript là loại yếu. Vâng, đó là cưỡng chế. Nhưng sự ép buộc không bao giờ nên áp dụng cho sự bình đẳng.

Nhân tiện, Crockford có ý kiến ​​mạnh mẽ. Nhưng bạn biết gì không? Anh ấy đúng ở đây!

FWIW Tôi hiểu rằng có, và tôi đã đích thân gặp phải những tình huống ==thuận tiện! Giống như lấy đầu vào chuỗi cho các số và, giả sử, so sánh với 0. Tuy nhiên, đây là hack. Bạn có sự thuận tiện như một sự đánh đổi cho một mô hình không chính xác của thế giới.

TL; DR: giả là một khái niệm tuyệt vời. Nó không nên mở rộng đến bình đẳng.