JSLint를 사용하여 JavaScript를 참조하고 있는데, JSLint가 대체하기 위한 많은 제안을 반환하고 있습니다.==(두 개의 등호)와 함께===(3개의 등호) 비교와 같은 일을 할 때idSele_UNVEHtype.value.length == 0의 내부if진술.
교환에 따른 퍼포먼스상의 이점이 있습니까?==와 함께===?
많은 비교 연산자가 존재하기 때문에 성능 개선은 환영받을 것이다.
유형 변환이 이루어지지 않으면 퍼포먼스가 향상됩니까?==?
질문에 대한 답변
완전 동등 연산자(===)는 추상 등호 연산자와 동일하게 동작합니다(==)는 타입 변환이 이루어지지 않으며 타입이 동일해야 동일하다고 간주됩니다.
레퍼런스: Javascript 튜토리얼: 비교 연산자
그==연산자는 필요한 유형 변환을 수행한 후 동등성을 비교합니다.그===연산자는 변환을 수행하지 않으므로 두 값이 동일한 유형이 아닌 경우===간단히 돌아오다false둘 다 똑같이 빠릅니다.
Douglas Crockford의 뛰어난 JavaScript를 인용하면 다음과 같습니다. 좋은 부분,
JavaScript에는 2개의 등호 연산자 세트가 있습니다.
===그리고.!==, 그리고 그들의 사악한 쌍둥이.==그리고.!=좋은 제품은 예상대로 작동합니다.2개의 오퍼랜드의 타입이 같고 값이 같을 경우===생산하다true그리고.!==생산하다false악당 쌍둥이는 피연산자가 같은 유형일 때는 옳은 일을 하지만, 만약 그들이 다른 유형일 경우, 그들은 값을 강요하려고 시도한다.그들이 그렇게 하는 규칙은 복잡하고 기억할 수 없다.다음은 몇 가지 흥미로운 사례입니다.'' == '0' // false 0 == '' // true 0 == '0' // true false == 'false' // false false == '0' // true false == undefined // false false == null // false null == undefined // true ' trn ' == 0 // true
이동성의 결여는 우려할 만한 일이다.제 조언은 절대 사악한 쌍둥이를 이용하지 말라는 것입니다.대신 항상 사용하세요.
===그리고.!==. 방금 표시된 모든 비교 결과false와 함께===교환입니다.
업데이트:
@Casebash에 의해 코멘트나 @Phillip Laybaert의 오브젝트에 관한 answer에서 좋은 지적이 제기되었습니다.오브젝트의 경우,==그리고.===(특별한 경우를 제외하고) 서로 일관되게 행동한다.
var a = [1,2,3]; var b = [1,2,3];
var c = { x: 1, y: 2 }; var d = { x: 1, y: 2 };
var e = "text"; var f = "te" + "xt";
a == b
// false a === b
// false
c == d
// false c === d
// false
e == f
// true e === f
// true 특별한 경우는 프리미티브를 동일한 프리미티브로 평가되는 오브젝트와 비교하는 경우입니다.이러한 오브젝트의 특성으로 인해toString또는valueOf방법.예를 들어 string primitive와 string object를 비교하여String컨스트럭터
"abc" == new String("abc")
// true "abc" === new String("abc")
// false 여기에서는,==연산자가 두 개체의 값을 확인하고 반환하는 중입니다.true단,===같은 타입이 아닌 걸 보고 다시 돌아오는 거야false어떤 게 맞습니까?비교하려는 항목에 따라 다릅니다.제 조언은 질문을 완전히 생략하고String생성자를 사용하여 문자열 리터럴에서 문자열 개체를 만듭니다.
언급
http://www.ecma-international.org/ecma-262/5.1/ #sec-11.9.3
사용방법==연산자(등가)
true == 1; //true, because 'true' is converted to 1 and then compared "2" == 2;
//true, because "2" is converted to 2 and then compared 사용방법===연산자(아이덴티티)
true === 1; //false "2" === 2;
//false 이는 등호 연산자가 강제 유형을 적용하기 때문입니다. 즉, 인터프리터는 비교하기 전에 암묵적으로 값을 변환하려고 합니다.
한편, 아이덴티티 연산자는 타입 강제를 실시하지 않기 때문에, 비교시에 값을 변환하지 않습니다.
여기 두 사람 사이의 평등 비교의 흥미로운 시각화가 있다.==그리고.===.
출처 : https://github.com/dorey/JavaScript-Equality-Table (영어, 통합 데모)
var1 === var2
사용시===JavaScript 동등성 테스트에서는 모든 것이 그대로입니다.
평가되기 전에 변환되는 것은 없습니다.
var1 == var2
사용시==JavaScript 동등성 테스트에서는 펑키한 변환이 이루어집니다.
Javascript의 평등 요약
결론:
에서 발생하는 펑키한 변환에 대해 완전히 이해하지 않는 한 항상 를 사용해 주십시오.==.
여기 답변에서 평등이란 어떤 의미인지 하나도 못 읽었어요라고 말하는 사람도 있을 것이다===동일하고 같은 유형을 의미하지만 사실은 그렇지 않습니다.이는 실제로 두 오퍼랜드가 동일한 객체를 참조하거나 값 유형의 경우 동일한 값을 갖는다는 것을 의미합니다.
다음 코드를 사용합니다.
var a = [1,2,3]; var b = [1,2,3]; var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type) var ac_eq = (a === c); // true 이쪽도 마찬가지입니다.
var a = { x: 1, y: 2 }; var b = { x: 1, y: 2 }; var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type) var ac_eq = (a === c); // true 또는 다음과 같은 경우도 있습니다.
var a = { }; var b = { }; var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type) var ac_eq = (a === c); // true 이 동작이 항상 명백한 것은 아닙니다.이 이야기에는 동등하고 같은 타입이 되는 것 말고도 더 많은 것이 있다.
규칙은 다음과 같습니다.
값 유형(숫자):
a === btrue를 반환한다.a그리고.b같은 가치를 가지며 같은 타입이다
참조 유형의 경우:
a === btrue를 반환한다.a그리고.b정확히 같은 대상을 참조하다
문자열의 경우:
a === btrue를 반환한다.a그리고.b두 문자열 모두 동일한 문자를 포함합니다.
스트링: 특별한 케이스…
문자열은 값 유형이 아니지만 Javascript에서는 값 유형처럼 동작하기 때문에 문자열의 문자가 같고 길이가 같을 때(세 번째 규칙에서 설명한 바와 같이) “동일”합니다.
이제 흥미로워집니다.
var a = "12" + "3"; var b = "123";
alert(a === b); // returns true, because strings behave like value types 하지만 이건 어때?
var a = new String("123"); var b = "123";
alert(a === b); // returns false !! (but they are equal and of the same type) 문자열이 가치 유형처럼 행동한다고 생각했는데?누구에게 묻느냐에 따라…이 경우 a와 b는 같은 타입이 아닙니다. a종류Object,하는 동안에b종류string. 를 사용하여 문자열 개체를 만듭니다.String컨스트럭터는 타입의 무언가를 창조한다Object대부분의 경우 문자열로 동작합니다.
이 조언을 덧붙이겠습니다.
확실하지 않은 경우 사양을 읽어 보십시오!
ECMA-262는 JavaScript가 방언인 스크립트 언어 사양입니다.물론 실제로는 처리 방법에 대한 난해한 정의보다 가장 중요한 브라우저가 어떻게 동작하는지가 더 중요합니다.그러나 새로운 String(“a”) !== “a”의 이유를 이해하는 것은 도움이 됩니다.
이 문제를 명확하게 하기 위해 사양서를 읽는 방법을 설명해 주세요.나는 이 아주 오래된 주제에서 아무도 매우 이상한 효과에 대한 답을 몰랐다는 것을 알았다.따라서 스펙을 읽을 수 있다면 당신의 직업에 큰 도움이 될 것입니다.그것은 습득한 기술이다.그럼 계속 진행합시다.
===에 대한 PDF 파일을 검색하면 사양의 56페이지(11.9.4)로 이동합니다. Strict Equals 연산자( === )와 특정 용어를 검색한 결과 다음과 같이 나타납니다.
11.9.6 엄격한 동등성 비교 알고리즘
x === y 비교(x와 y는 값)는 참 또는 거짓을 생성합니다.이러한 비교는 다음과 같이 수행됩니다.
1. 유형(x)이 유형(y)과 다를 경우 false를 반환합니다.
2. 유형(x)이 정의되지 않은 경우 true를 반환합니다.
3. Type(x)이 Null이면 true를 반환합니다.
4. 타입(x)이 번호가 아닌 경우 스텝 11로 넘어갑니다.
5. x가 NaN이면 false를 반환합니다.
6. y가 NaN이면 false를 반환합니다.
7. x가 y와 같은 숫자 값이면 true를 반환합니다.
8. x가 +0이고 y가 -0이면 true를 반환합니다.
9. x가 -0이고 y가 +0이면 true를 반환합니다.
10. 거짓으로 반환한다.
11. Type(x)이 String이면 x와 y가 정확히 같은 일련의 문자(같은 길이와 대응하는 위치에 같은 문자)이면 true를 반환하고 그렇지 않으면 false를 반환합니다.
12. Type(x)이 Boolean이면 true를 반환하고, 그렇지 않으면 false를 반환합니다.
13. x와 y가 같은 물체를 가리키거나 서로 연결된 물체를 가리키는 경우 true를 반환합니다(13.1.2 참조).그렇지 않으면 false를 반환합니다.
흥미로운 것은 11단계입니다.네, 문자열은 값 유형으로 취급됩니다.그러나 이것은 새로운 String(“a“) !== “a” 이유를 설명하지 않습니다.ECMA-262에 준거하지 않는 브라우저가 있습니까?
너무 빨리 하지 마!
오퍼랜드의 종류를 확인합니다.type of()로 포장하여 직접 사용해 보십시오.새로운 String(“a”)이 오브젝트이며 스텝1이 사용되고 있습니다.타입이 다르면 false를 반환합니다.
새로운 String(“a”)이 문자열을 반환하지 않는 이유가 궁금하다면 사양을 읽어보는 연습을 해보는 것은 어떨까요?재미있게 보내!
Aidiakapi는 다음과 같은 코멘트를 남겼다.
사양에서
11.2.2 새로운 운영자:
Type(컨스트럭터)이 Object가 아닌 경우 TypeError 예외를 발생시킵니다.
즉, String이 Object 유형이 아니면 새 연산자와 함께 사용할 수 없습니다.
new는 String 컨스트럭터에서도 항상 오브젝트를 반환합니다.아아!문자열의 값 의미론(스텝 11 참조)이 없어집니다.
그리고 이것은 마지막으로 새로운 String(“a”)!== “a”를 의미합니다.