좋은 검사 (linting) 도구는 프로젝트 코딩 규칙을 따라야 할 것을 확인합니다.
: 특징과 장점과 네 개의 인기있는 대안의 단점에서 살펴 보자 JSLint , JSHint , JSCS 및 ESLint .
JSLint
JSLint는 가장 오래된 도구 중 하나입니다. 2002 년 더글러스 크록 포드는 경험 본질적 부분에 자바 스크립트 언어의 의무적 사용을 기반으로,이 도구를 개발했다. 당신은 본질에 동의하면 JSLint는 좋은 도구가 될 수 있습니다 - 지금 바로, 바로 설치할 수 있습니다.
구성 또는 확장 할 수없는 단점 JSLint. 당신은 중복 기능을 금지하고, 문서의 부족으로 많은 수 없습니다. 공식 문서는 예를 들어, 편집기의 정보에 통합하는 방법을없는, 매우 친절하지 않습니다.
이점
- 구성이 완료 매개 변수 (당신이 구현 규칙에 동의하면 다음), 그것은 직접 사용할 수 있습니다
결점
- 당신이 매개 변수 설정을 변경하려는 경우, 다음 문제가 어떤 구성 파일을 JSLint 없습니다
- 구성 옵션이 제한 규칙의 대부분은 차단할 수 없습니다
- 사용자 정의 규칙을 추가 할 수 없습니다
- 어떤 규칙 문서 없습니다
- 어떤 인한 오류 규칙은 이해하기 어렵다
JSHint
JSHint은 (포크 JSLint의) 구성 JSLint 버전입니다. 각 규칙을 구성하고 쉽게 큰 프로젝트에 대한 JSHint을 사용할 수있게 구성 파일에 배치 할 수 있습니다. 당신이 정확히 각 규칙의 역할을 알 수 있도록 JSHint 모든 규칙, 매우 친절 문서가있다. 에디터에 통합하는 것은 간단합니다.
JSHint 작은 단점은 느슨한 기본 구성을 가지고 있다는 것입니다. 이 방법은 당신이 그것을 사용하기 전에, 당신은 몇 가지 설정을 할 필요가있다. 그리고 ESLint은 활성화 또는 비활성화 특정 오류 메시지가 JSHint 더 어려운이다로 변경하는 규칙을 알고 싶은 비교.
이점
- 대부분의 설정을 구성 할 수 있습니다
- 지원 프로파일은 쉬운 대형 프로젝트에 사용
- 그것은 등 jQuery를, QUnit, NodeJS, 모카, 같은 많은 라이브러리의 지원을하고있다
- 기본 ES6 지원
결점
- 오류가있는 규칙 결과를 알 하드
- 강제 옵션 및 느슨한 옵션 : 옵션의 두 가지 유형이 있습니다. 그것은 혼란의 구성을 만든다
- 그것은 사용자 정의 규칙을 지원하지 않습니다
JSCS
JSCS는 당신이 그것을 프로파일을 제공하거나 구성 항목에 말하지 않으면? 다른 달리, JSCS는 아무것도하지 않습니다. 이것은 큰 문제가되지 않습니다, 그래서 당신은 자신의 웹 사이트에서 다운로드를 구성 할 수 있습니다, 그것은 jQuery와 구글 스타일 기본 사전 설정을 코딩 등의 프리셋을 많이했다.
그것은 당신이 플러그인에 의해 사용자 정의 규칙을 만들 수 있습니다, 90 개 이상의 서로 다른 규칙이 있습니다. JSCS 또한이 도구는 특정 입력 형식을 필요로 통합하는 것이 더 쉬울 수 있습니다 만드는, 사용자 정의 보고서를 지원합니다.
JSCS는 코드 스타일 검사기입니다. 그것은 단지 코드가 오류 또는 잠재적 인 오류를보고하지 않습니다 서식과 관련된 문제를 캡처하는이 수단. 따라서, 유연성의 부족은 다른 도구에 비해 있지만, 특정 코딩 스타일을 적용해야하는 경우, JSCS 잘 할 수 있습니다.
이점
- 쉽게 다른 도구와 통합, 사용자 정의 보고서 지원
- 사용 가능한 코딩 스타일 중 하나에 따라, 준비 만든 사전 설정 프로파일을 쉽게 설정할 수있는 경우가 될
- 이 오류가 발생할 수있는 어떤 규칙 밖으로 쉽게 찾을 수 있도록 보고서에이 표시되고, 규칙의 이름을 포함
- 당신은 확장하는 사용자 정의 플러그인을 사용할 수 있습니다
결점
- 유일한 코딩 스타일의 위반을 확인합니다. 잠재적 본 JSCS 버그 그러한 않는 변수, 전역 변수 등 또는 우발적으로 체크 할 수 없다.
- 네 도구 느린,하지만 사용하지 않는 문제
ESLint
ESLint는 네 아웃의 최신입니다. 사용자 정의 규칙, 규칙의 많은 수의 확장이 용이하도록 설계하고 더 쉽게 플러그인으로 설치됩니다. 그것은 간결한 출력을 제공하지만, 당신은 항상 규칙이 오류 메시지가 발생할 수있는 알 수 있도록 기본적으로 규칙의 이름을 포함합니다.
ESLint 문서는 어떤 영향 또는 누락이있을 수 있습니다. 규칙 목록은 쉽게 따라하고, 논리적 범주로 분류되어 있지만, 어떤 장소에서 구성 지침은 약간 혼란. 그러나, 통합 편집기, 플러그인 및 링크 예제를 제공한다.
이점
- 유연 : 모든 규칙을 켜거나 끄 될 수있는 몇 가지 규칙과 몇 가지 추가 구성 항목
- 확장이 용이하고, 가능한 많은 플러그인이있다
- 이해 출력
- 규칙은 유용한에서 확인 다른 관리자를 사용할 수없는 등 ESLint 오류에 포함
- 지원 ES6, 유일하게 지원 JSX의 도구
- 사용자 정의 보고서 지원
결점
- 그것은 몇 가지 구성이 필요합니다
- 천천히,하지만 큰 문제
나의 추천
이 네 가지 도구에서, 내 선택은 ESLint입니다. JSHint는 엄격하고 구성 할 수 없습니다, 그리고 JSHint는 확장 메커니즘의 부족. 단지 코딩 스타일을 확인하는 경우, JSCS은 좋은 선택이지만, ESLint 코드 스타일 검사뿐만 아니라, 당신의 코드에서 버그 및 기타 문제를 확인할 수 있습니다.
(그들은 그것을 호출하는 것 때문에, 또는 ES2015)는 ES6를 사용하는 경우도 ESLint 현명한 선택. 상기 도구에 대한 ESLint ES6 지원은 가장 널리 사용되는.
당신이 ESLint을 시도 싶은 경우에, 나는 5 단계 빠른 시작 가이드를 만들었습니다. 당신은 매우 쉽게 시작하자. 당신은 할 수 있습니다 내 웹 사이트에서 ESLint 5 단계 빠른 시작 안내서를 다운로드 .
JSHint 두 번째 선택이 될 것입니다. 당신이 고급 기능 ESLint이 필요하지 않은 경우, JSHint 올바른 구성으로 많은 문제를 캡처합니다. 당신이 (등 들여 쓰기, 중괄호,) 코딩 스타일 검사 외에 다른 검사가 필요하지 않은 경우 JSCS, 그것은 최선의 선택이 될 것입니다 가능한 많은 규칙을 가지고 있습니다.
나는 JSLint를 추천하는 것은 매우 주저했다. 다른 도구는 같은 일을하지만, 이러한 규칙을 준수하도록 사용자를 강요하지 않습니다. 유일한 예외는 당신이이 경우 규칙을 적용하는 사람들에 동의하는 일 즉, 추가 연구의 가치가있다.
검사 도구는 문제를 해결하는 좋은 방법이지만, 그것은 단지 규칙과 일치하는 많은 오류를 찾을 수 있습니다. 보다 안전한 자동 캡처 버그를 들어, 내가 단위 테스트의 사용을 권장합니다. 코드 리뷰는이 목적을 위해 이용 될 수있다.
어떻게 당신과 당신의 팀 코드 품질 할 그것을 보호하는 것입니다?
원본 링크 : https://www.sitepoint.com/comparison-javascript-linting-tools/