JSLint '==='가 필요하고 대신 '=='가 표시되었습니다.


90

최근에이 오류가 발생했을 때 JSLint를 통해 일부 코드를 실행했습니다. 이 오류에 대해 재미 있다고 생각하는 것은 모든 ==가 ===이어야한다고 자동으로 가정한다는 것입니다.

정말 말이 되나요? 유형을 비교하고 싶지 않은 인스턴스를 많이 볼 수 있었는데, 이것이 실제로 문제를 일으킬 수 있다고 걱정됩니다.

"예상"이라는 단어는이 작업을 매번 수행해야 함을 의미합니다 ..... 그게 말이 안되는 것입니다.


7
JSLint에서도이 문제를 만났습니다. ==에서 ===로 업데이트했으며 실제로 이전 작업 코드가 손상되었습니다.
kemiller2002

5
코드에 100 줄이 넘으면 jslint를 통과하지 못합니다. 실제로 불가능합니다.

3
"브로크"는 너무 강한 단어입니다. 그것은 당신의 코드의 의미를 바 꾸었습니다. 당신이 myVar == null수표 를하고 있었다면 , 네, 큰 변화입니다. ; ^) Crockford의 주장은 그것이 코드의 의미를 더 정확하게 만들었고 논쟁하기 어렵습니다.
ruffin 2013 년

답변:


127

유형 변환이 작동 하는 방식===이해 하지 않고 맹목적으로 IMO를 사용 하는 것은 의미가 없습니다.

Equals 연산자에 대한 주요 두려움==비교되는 유형에 따른 비교 규칙이 연산자를 비전 이적으로 만들 수 있다는 것입니다. 예를 들면 다음과 같습니다.

A == B AND
B == C

실제로 다음을 보장하지는 않습니다.

A == C

예를 들면 :

'0' == 0;   // true
 0  == '';  // true
'0' == '';  // false

Strict Equals 연산자 ===는 동일한 유형의 값을 비교할 때 실제로 필요하지 않습니다. 가장 일반적인 예입니다.

if (typeof foo == "function") {
  //..
}

우리는의 결과 비교 typeof연산자, 항상 문자열 로, 문자열 리터럴을 ...

당신이 강제 형 변환 규칙을 알고있을 때 무언가가있는 경우 또는, 예를 들어, 확인 null또는 undefined뭔가 :

if (foo == null) {
  // foo is null or undefined
}

// Vs. the following non-sense version:

if (foo === null || typeof foo === "undefined") {
  // foo is null or undefined
}

1
나는 JSLint의이 규칙이 싫다. 진짜 문제는 사람들이 이해하지 못하는 방식으로 연산자를 사용해서는 안된다는 것입니다 (아이러니하게도 이들은 종종 '==='를 '=='로 맹목적으로 대체하는 동일한 종류의 사람들입니다). 물론, 숫자 0을 다양한 문자열과 비교할 때 발생하는 몇 가지 일반적인 경우가 있지만 0 == '이것은 문자열입니다'와 같은 관련없는 데이터를 비교하는 경우-코드에 double equal보다 더 큰 문제가있을 수 있습니다! 어떤 유형을 다루고 있는지 확실히 알고 있고 그들이 ==와 어떻게 상호 작용하는지 정확히 알고 있다면 그것을 사용해야한다고 생각합니다.

3
@Jon ===연산자 의 요점 은 코드 명확성입니다. ==ID 운영자만큼 명확하고 이해할 수 없기 때문에 사용할 합리적인 상황이 없습니다 . 연산자를 이해하는지 여부가 아니라 거의 비용없이 코드를 더 쉽게 읽을 수있는 연산자를 사용하는 것입니다. ID 연산자에 반대하는 유일한 개발자는 솔로 개발자와 팀에서 일하지 않는 사람들입니다. 정의에 따르면 코드는 충분한 눈으로 검토되지 않습니다.
Alternatex

2
== null 비교가 거의 필수적이라는 것을 알았습니다. 코드를 잘 테스트하면 문제가 훨씬 덜 중요해집니다.
Jon

1
실제로 필요한 테스트를 수행하기 위해 == 사용이 필수적인 경우가 있습니다. foo.toString ()이 예측 가능한 방식으로 수행되고 해당 출력에 대해 일반 문자열을 테스트해야하는 경우 foo == stringToTest를 작성하는 것이 foo.toString () === stringToTest보다 훨씬 깨끗합니다.
Crispen Smith

2
@Alternatex 요점이 명확하다면 TRIPLE이 같으면 안됩니다! 초보자는 그것을 이해하지 못합니다. 적어도 double equals는 다른 언어에서 알려져 있습니다. 또한 there is no reasonable situation심한 오해입니다. (네이티브) Javascript 유형 NumberString. 그들의 존재는 자바 스크립트 작성자가 ==. new String('hi') === 'hi'평가하는 false것이 매우 명확 하다고 생각하십니까 ? 'hi'문자열과 문자열을 모두 받아들이는 것에 대해 함수 인수를 테스트하는 코드 스 니펫을 작성하고 명확하게 알려주십시오.
Stijn de Witt

25

JSLint는 본질적으로 Javascript 구문이 허용하는 것보다 더 방어 적입니다.

JSLint 문서에서 :

==!=연산자는 비교하기 전에 강제 형 변환을한다. 이것은 사실이되기 때문에 나쁘다 ' \t\r\n' == 0. 이것은 유형 오류를 가릴 수 있습니다.

다음 값 중 하나와 비교할 때 ===or !==연산자 (유형 강제 변환을 수행하지 않음)를 사용하십시오.0 '' undefined null false true

값이 진실 인지 거짓 인지에만 관심이 있다면 짧은 형식을 사용하세요. 대신에

(foo != 0)

그냥 말해

(foo)

그리고 대신

(foo == 0)

말하다

(!foo)

===!==운영이 바람직하다.


8
나는 JSLint의 사람들이 결코 빠져 나가지 않는 매우 높은 상아탑에서 일한다고 결론 내려야합니다. Javascript는 연산자 와 함께 사용 하도록 설계되었습니다== . 이것은 ===특별한 경우입니다 ... JSLint는 사용하는 ==것이 어떻게 든 잘못된 것처럼 보이게하려고합니다 ... 그러나 이것을 시도하십시오 : var x = 4, y = new Number(4); if (x == y) {alert('Javascript depends on == just embrace it!');}. 프리미티브 유형에는 해당 클래스 ( Number, String) 를 대체하는 해당 클래스가 있으며 Javascript는 ==연산자에 따라 이를 자연스럽게 비교할 수 있습니다.
Stijn de Witt

17

JSLint는 좋은 JavaScript가 무엇인지에 대한 한 사람의 생각을 강요한다는 것을 명심하십시오. 제안 된 변경 사항을 구현할 때는 여전히 상식을 사용해야합니다.

일반적으로 유형과 값을 비교하면 코드가 더 안전 해집니다 (유형 변환이 예상 한대로 작동하지 않을 때 예기치 않은 동작이 발생하지 않습니다).


4
게다가 프로그래머만큼 상황에 맞지 않을 수도 있습니다. 대부분의 사용자가 시스템에 내재 된 자동 유형 변환 (예 : 폭력- "내가 억압받는 데 도움이 돼요!")에 걸려 넘어진다는 사실을 기반으로 작동합니다.
Rudu

14

Triple-equal은 double-equal과 다릅니다. 두 변이 동일한 값인지 확인하는 것 외에도 triple-equal은 동일한 데이터 유형인지 확인하기 때문입니다.

그래서 ("4" == 4)사실이지만 ("4" === 4)거짓입니다.

Triple-equal은 또한 약간 더 빠르게 실행됩니다. JavaScript는 답을 제공하기 전에 유형 변환을 수행하는 데 시간을 낭비 할 필요가 없기 때문입니다.

JSLint는 모호한 버그를 줄이기 위해 의도적으로 JavaScript 코드를 최대한 엄격하게 만드는 것을 목표로합니다. 데이터 유형을 존중하도록 강요하는 방식으로 코드를 작성하기 위해 이러한 종류의 것을 강조합니다.

그러나 JSLint의 좋은 점은 단지 가이드 일 뿐이라는 것입니다. 그들이 사이트에서 말했듯이, 당신이 아주 좋은 자바 스크립트 프로그래머 라 할지라도 그것은 당신의 감정을 상하게 할 것입니다. 그러나 그 조언을 따를 의무가 있다고 느껴서는 안됩니다. 그것이 말하는 것을 읽고 이해했지만 코드가 깨지지 않을 것이라고 확신한다면, 아무것도 변경하지 않아도됩니다.

아무것도하지 않을 것이라는 경고를 받고 싶지 않다면 JSLint에게 검사 범주를 무시하도록 지시 할 수도 있습니다.


3
나는 "==="이 무엇인지 묻지 않았기 때문에 왜 대답했는지 모르겠습니다.
Metropolis

8
@Metropolis : 다른 이유가 없다면, 모르는 사람이 답을 읽었을 때를 대비하여 배경으로 사용합니다. 그래도 그 후 문단에서 귀하의 질문에 대답하려고 노력했습니다.
Spudley

추가 및 유용한 정보에 대한 @Spudley + 1
벤 주니어

1
네, 10-100 배 더 빠릅니다 : jsperf 속도 테스트
vladkras 2014 년

8

http://javascript.crockford.com/code.html 의 인용문 :

=== 및! == 연산자.

=== 및! == 연산자를 사용하는 것이 거의 항상 좋습니다. == 및! = 연산자는 유형 강제를 수행합니다. 특히 잘못된 값과 비교하기 위해 ==를 사용하지 마십시오.

JSLint는 매우 엄격하며 'webjslint.js'는 자체 유효성 검사도 통과하지 못합니다.


좋은 설명입니다. webjslint.js유효성을 검사하지 않는 것에 대한 사실 입니다. 지금 제가 보는 대부분의 오류는 간격과 관련이 있습니다. 분명히 JSLint를 사용하여 JavaScript를 검토 할 때 상식과 합리적인 판단을 사용해야합니다.
hotshot309 dec.

이 단어를 사용하면 always자동적으로이 인용문이 지혜로 인정되지 않습니다. 똑똑한 프로그래머는 독단적이지 않습니다. 주어진 상황에서 가장 좋은 것을 사용합니다. 그리고 그들은 언어의 핵심에 내장 된 모든 도구를 환영하고 받아들 just never touch it입니다. 결론 : 내 코드가 더 짧아서 (단지 한 =문자 를 저장하는 것이 아니라 ) 내 사이트가 더 적은 대역폭 비용으로 더 빨리로드되므로 사용자에게 더 나은 서비스를 제공합니다.
Stijn de Witt 2015 년

4

거짓 여부를 테스트하려는 경우. JSLint는 허용하지 않습니다.

if (foo == null)

하지만 허용합니다

if (!foo)

===JSLint가 권장하는를 사용하십시오 .
clickbait 2015-06-24

1
@NarawaGames이 솔루션은 완벽하게 허용됩니다.

이 대답은 좋지 않습니다. 문제는 둘 다 다른 것을 의미한다는 것입니다. foo == nullnull 또는 undefined를 확인합니다. !foonull, undefined, 0 및 빈 문자열을 확인합니다.
Markos

@Markos이 답변은 JSLint를 행복하게 만들고 코드 논리를 그대로 유지하는 데 도움이되는 대안이되어야합니다. 이것이 제가 "위조 여부를 확인하는 경우"라는 대답 앞에 접두사를 붙인 이유입니다
nano2nd

3

이 질문을 설명하고 NetBeans (from) 7.3이이 경고를 표시하기 시작한 이유를 설명하기 위해 누군가가 이것을 버그로보고했을 때 NetBeans 버그 추적기의 응답에서 발췌 한 것입니다.

JavaScript에서 == 대신 ===를 사용하는 것이 좋습니다.

== 및! = 연산자는 비교하기 전에 유형 강제를 수행합니다. 이것은 '\ t \ r \ n'== 0이 참이되기 때문에 나쁘다. 이것은 유형 오류를 가릴 수 있습니다. JSLint는 ==가 올바르게 사용되고 있는지 확실하게 확인할 수 없으므로 == 및! =를 전혀 사용하지 않고 항상 더 안정적인 === 및! == 연산자를 사용하는 것이 가장 좋습니다.

참고


1
방금 Netbeans를 사용 하여이 오류를 발견했습니다. 그들이 제공 한 기괴한 사례로 인해 경고 심각도로 이것을 취급하는 것이 이상합니다.
omikes dec

1
내 말은, 사실이지만 비교 된 두 가지가 같은 유형이라는 것을 그 사람이 알고있는 사용 사례가 많기 때문에 캐리지 리턴을 숫자와 비교할 수있는이 이상한 경우가 이상해 보입니다. 0은 ==의 모든 사용이 잘못된 것으로 간주되는 이유입니다. 나는 유형 변환이 수행되지 않았기 때문에 === 더 빠르다는 것을 알고 있습니다. 나는 netbeans 이전에 이것을 발견하지 못했다는 것에 놀랐습니다.
omikes

@oMiKeY 예, 당신이 의미하는 바를 알았습니다, 그들은 더 현실적인 예를 제공 할 수있었습니다!
EM-Creations

2

정말 문제를 일으킬 수는 없습니다. 단지 조언을 제공하는 것뿐입니다. 가져 가든지 남겨 두든지. 즉, 그것이 얼마나 영리한지 잘 모르겠습니다. 문제로 제시하지 않는 상황이있을 수 있습니다.


그러나 "예상"이라는 단어가 사용되는 이유는 무엇입니까? 그것은 당신이 항상 이것을해야하는 것처럼 들리게합니다.
Metropolis

4
평가자는 검증을 시도하면서 유효한 응답을 찾고 있습니다. 유효한 응답을받지 못하면 예상 한 것과 다릅니다. 유효성 검사기는 모든 것이 정상이라는 가정으로 시작하여 코드를 탐색 할 때 오류를 지적합니다. 유효하지 않은 응답이 무엇인지 반드시 이해하는 것은 아니며, 유효하지 않은 응답을 볼 때만 알뿐입니다. 또한 반대 방향으로 작동 할 수 있으며, 악의적 인 규칙에 따라 의도적으로 잘못된 코드를 검색 할 수 있습니다. 화이트리스트와 블랙리스트.
Rushyo

질문은 "정말 말이 되는가?"였습니다. 그 질문이 주어지면 그렇습니다. 또한 5 년 전 이었습니다. 예수.
Rushyo는
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.