[javascript] JSLint 또는 JSHint JavaScript 유효성 검사를 사용해야합니까? [닫은]

현재 JSLint에 대해 JavaScript의 유효성을 검사하고 진행 중이며, 특히 Jquery 라이브러리 작업에서 더 나은 JavaScript를 작성하는 데 도움이됩니다.

나는 JSLint 의 포크 인 JSHint만났다 .
그래서 JavaScript가 많이 구동되는 웹 응용 프로그램이 궁금합니다.

  • JSLint 또는 JSHint?

유효성 검사 메커니즘을 결정하고 앞으로 나아가 클라이언트 측 유효성 검사에 사용하고 싶습니다.

그리고 jshint와 jslint의 차이점은 무엇입니까? 단일 자바 스크립트 예제로 설명하십시오.

연결:

  1. jshinthttp: //www.jshint.com/

  2. jslinthttp: //jslint.com/



답변

[편집]
이 답변은 수정되었습니다. 문맥에 따라 아래의 원래 답변을 남기고 있습니다 (그렇지 않으면 의견이 의미가 없습니다).

이 질문을 처음 받았을 때 JSLint는 JavaScript의 주요 보푸라기 도구였습니다. JSHint는 JSLint의 새로운 포크이지만 아직 원래 버전과 크게 다르지 않았습니다.

그 이후로 JSLint는 거의 정적으로 유지되었지만 JSHint는 많은 변화를 겪었습니다. JSLint의 더 적대적인 규칙을 버리고 새로운 규칙을 많이 추가했으며 일반적으로 더 유연 해졌습니다. 또한 더 유연하고 규칙 옵션이 더 많은 다른 도구 인 ESLint를 사용할 수 있습니다.

내 원래의 대답에서, 나는 당신이 JSLint의 규칙을 강요해서는 안된다고 말했다. 경고가 발생하는 이유를 이해 한 경우 경고를 해결하기 위해 코드를 변경해야하는지 여부를 스스로 판단 할 수 있습니다.

2011 년부터 JSLint의 매우 엄격한 규칙 세트를 사용하면 합리적인 조언이되었습니다. JSLint 테스트를 통과 할 수있는 JavaScript 코드 세트는 거의 없었습니다. 그러나 오늘날의 JSHint 및 ESLint 도구에서 사용할 수있는보다 실용적인 규칙을 사용하면 경고없이 코드를 통과시키는 것이 훨씬 현실적인 제안입니다.

때때로 당신의 의도적으로 행한 것에 대해 린터가 불만을 제기하는 경우가있을 수 ===있습니다 ==. 그러나 ESLint를 사용하면 eslint-disable문제의 행 주위 를 지정하는 옵션이 있으므로 나머지 코드가 규칙을 준수하면서 경고없이 경고 메시지를 전달할 수 있습니다. (그런 일을 너무 자주하지 마십시오!)


[원래 답변 추종자]

반드시 JSLint를 사용하십시오. 그러나 결과에 대해 경고하고 경고하는 모든 것을 고치지 마십시오. 코드를 개선하는 데 도움이되고 잠재적 인 버그를 찾는 데 도움이되지만 JSLint가 불평하는 모든 문제가 실제 문제인 것은 아니므로 경고없이 프로세스를 완료해야한다고 생각하지 마십시오.

길이나 복잡성이 큰 Javascript 코드는 JSLint에서 아무리 잘 작성 되었든 경고를 생성합니다. 내가 믿지 않는다면 JQuery와 같은 인기있는 라이브러리를 실행하십시오.

일부 JSLint 경고는 다른 경고보다 더 중요합니다.주의해야 할 경고와 중요하지 않은 경고를 학습하십시오. 모든 경고를 고려해야하지만 지정된 경고를 지우도록 코드를 수정해야 할 의무는 없습니다. 코드를보고 만족하는지 결정해도됩니다. JSlint가 싫어하는 것이 실제로 옳은 일이있는 경우가 있습니다.


답변

tl; dr 테이크 아웃 :

자신이나 팀을위한 매우 높은 표준을 찾고 있다면 JSLint. 그러나 그 표준은 반드시 표준이 아니며 표준 중 일부는 Doug Crockford라는 자바 신에서 독단적으로 우리에게옵니다. 좀 더 융통성을 원하거나 팀에 JSLint의 의견에 동의하지 않거나 정기적으로 JS와 다른 C 계열 언어 사이를 오가는 오래된 전문가가 있으면 JSHint를 사용해보십시오.

긴 버전 :

포크 뒤의 추론은 JSHint가 존재하는 이유를 잘 설명합니다.

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to -jshint /

그래서 아이디어는 그것이 Crockford가 아닌 “커뮤니티 주도”라는 생각입니다. 실제로, JSHint는 일반적으로 JSLint가 고집하는 몇 가지 문체와 작은 구문 “의견”에 대해 좀 더 관대합니다 (또는 적어도 구성 가능하거나 불가지론).

예를 들어, 아래 A와 B가 모두 좋다고 생각하거나 B에서 사용할 수없는 A의 측면 중 하나 이상으로 코드를 작성하려는 경우 JSHint가 적합합니다. B가 유일한 올바른 옵션이라고 생각한다면 … JSLint. 나는 다른 차이점이 있다고 확신하지만 이것은 몇 가지를 강조합니다.

A) JSHint를 즉시 전달-JSLint 실패

(function() {
  "use strict";
  var x=0, y=2;
  function add(val1, val2){
    return val1 + val2;
  }
  var z;
  for (var i=0; i<2; i++){
    z = add(y, x+i);
  }
})();

B) JSHint와 JSLint를 모두 통과

(function () {
    "use strict";
    var x = 0, y = 2, i, z;
    function add(val1, val2) {
       return val1 + val2;
    }
    for (i = 0; i < 2; i += 1) {
        z = add(y, x + i);
    }
}());

개인적으로 JSLint 코드는 매우보기 좋으며, 내가 동의하지 않는 유일한 어려운 기능은 함수와 for-loop var i = 0선언 에서 하나 이상의 var 선언 과 함수 선언에 대한 공백 시행 의 증오입니다. .

JSLint가 시행하는 몇 가지 공백은 반드시 나쁘지는 않지만 가족의 다른 언어 (C, Java, Python 등)에 대한 꽤 표준적인 공백 규칙과 동기화되지 않는 경우가 많습니다. 자바 스크립트에서도 관례로 사용되었습니다. 하루 종일 다양한 언어로 작성하고 있으며 코드에서 Lint 스타일의 공백을 좋아하지 않는 팀원과 함께 작업하기 때문에 JSHint가 균형이 잘 맞습니다. 그것은 합법적 인 버그이거나 정말로 나쁜 형태의 물건을 잡지 만 JSLint가 내가 신경 쓰지 않는 문체 의견이나 구문 적 이명에 대해 (때로는 비활성화 할 수없는 방식으로) 짖지 않습니다.

많은 훌륭한 라이브러리는 Lint’able이 아니기 때문에 JSLint 중 일부는 단순히 “좋은 코드”(즉, 좋은 코드)의 1 버전을 푸시하는 것에 대한 아이디어가 있다는 것을 보여줍니다. 그러나 다시, 동일한 라이브러리 (또는 다른 좋은 라이브러리)는 아마도 힌트를 얻지 못할 수도 있습니다.


답변

자바 스크립트 린팅 프론트 에는 또 다른 성숙하고 적극적으로 개발 된 “플레이어”가 있습니다- ESLint:

ESLint는 ECMAScript / JavaScript 코드에서 발견 된 패턴을 식별하고보고하기위한 도구입니다. 여러면에서 JSLint 및 JSHint와 유사하지만 몇 가지 예외가 있습니다.

  • ESLint는 JavaScript 구문 분석에 Esprima를 사용합니다.
  • ESLint는 AST를 사용하여 코드의 패턴을 평가합니다.
  • ESLint는 완전히 플러그 가능하며 모든 단일 규칙은 플러그인이며 런타임에 더 추가 할 수 있습니다.

여기서 중요한 것은 사용자 정의 플러그인 / 규칙을 통해 확장 가능 하다는 것입니다 . 다른 목적으로 작성된 여러 개의 플러그인이 이미 있습니다. 중 다른 사람 이 있습니다 :

물론 선택한 빌드 도구를 사용하여 실행할 수 있습니다. ESLint .


답변

몇 주 전에 같은 질문이 있었고 JSLint와 JSHint를 모두 평가했습니다.

이 질문에 대한 답변과 달리 내 결론은 그렇지 않았습니다.

반드시 JSLint를 사용하십시오.

또는:

자신이나 팀을 위해 매우 높은 표준을 찾고 있다면 JSLint.

JSHint에서 JSLint와 거의 동일한 규칙을 구성 할 수 있습니다 . 따라서 달성 할 수있는 규칙에는 큰 차이가 없다고 주장합니다.

따라서 서로를 선택해야하는 이유는 기술적 인 것보다 정치적입니다.

우리는 마침내 다음과 같은 이유로 JSHint를 사용하기로 결정했습니다.

  • JSLint보다 더 구성 가능한 것 같습니다.
  • ( 남자 가 아무리 시원 할지라도) 1 인 쇼가 아닌 커뮤니티 주도형으로 보입니다 .
  • JSHint는 코드 스타일 OOTB와 JSLint를 더 잘 일치 시켰습니다.

답변

세 번째 제안 인 Google Closure Compiler (및 Closure Linter ) 도 제안 합니다. 여기서 온라인으로 사용해 볼 수 있습니다 .

Closure Compiler는 JavaScript 다운로드 및 실행 속도 향상을위한 도구입니다. JavaScript를위한 진정한 컴파일러입니다. 소스 언어에서 기계 코드로 컴파일하는 대신 JavaScript에서 더 나은 JavaScript로 컴파일됩니다. JavaScript를 구문 분석하고 분석하여 데드 코드를 제거하고 남은 것을 다시 작성하고 최소화합니다. 또한 구문, 변수 참조 및 유형을 확인하고 일반적인 JavaScript 함정에 대해 경고합니다.


답변

서문 : 글쎄요. 그러나 그것을 통과하기로 결정했습니다. 이 답변이 귀하와 다른 독자에게 도움이 되길 바랍니다.

나는 여기에서 조금 쫓겨났다

코드 힌트

JSLint와 JSHint는 사용하기에 좋은 도구이지만, 오랜 세월 동안 친구 @ugly_syntax가 부르는 것에 감사하게되었습니다 .

더 작은 디자인 공간 .

이것은 “선 (k) 수도사”와 매우 유사한 일반적인 원칙으로, 하나의 선택을 제한하고,보다 생산적이고 창의적 일 수 있습니다.

따라서 현재 선호하는 제로 구성 JS 코드 스타일 :

StandardJS .

업데이트 :

흐름 이 많이 향상되었습니다. 이를 통해 JS에 유형을 추가하여 많은 버그를 예방할 수 있습니다. 그러나 예를 들어 형식화되지 않은 JS와 인터페이스 할 때 방해가되지 않습니다. 시도 해봐!

빠른 시작 / TL; DR

standard프로젝트에 종속성으로 추가

npm install --save standard

그런 다음에 package.json다음 테스트 스크립트를 추가하십시오.

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

개발 중 snazzier 출력의 npm install --global snazzy경우 대신npm test .

참고 : 유형 검사와 휴리스틱

내 친구는 Elm이라는 디자인 공간을 언급 할 때 그 언어를 사용해 보라고 권합니다.

왜? JS는 실제로 특수 언어 클래스 인 LISP에서 영감을 얻었습니다. 형식화되지 않았습니다 . 같은 느릅 나무 또는 언어 Purescript가 되어 입력 기능 프로그래밍 언어입니다.

언어 또는 자신의 프로그램 규칙을 위반할 때 컴파일러가 사용자를 확인하고 안내 할 수 있도록 자유를 제한하십시오. 프로그램의 크기 (LOC)에 관계없이

우리는 최근 하급 동료에게 반응 형 인터페이스를 두 번 구현했습니다. 내가 말하는 것에 대한 아이디어를 얻을 수 있습니다.

비교 Main.elm(타이핑) ⇔index.js 되지 않은 테스트 없음)

(ps. 반응 코드는 관용적이지 않으며 향상 될 수 있음에 유의하십시오)

마지막 발언

실제로 JS 형식화되지 않았습니다. 형식화 된 프로그래밍 을 제안하는 사람은 누구입니까 을 입니까?

JS를 사용하면 우리는 다른 영역에 있습니다. 유형이 없으므로 올바른 유형을 제공하기 어렵거나 불가능한 것을 쉽게 표현할 수 있습니다 (확실히 유리 할 수 ​​있음).

그러나 유형이 없으면 프로그램을 확인할 필요가 거의 없으므로 테스트와 코드 스타일을 (더 적게 확장하기 위해) 도입해야합니다.

영감을 얻으 려면 LISP (예 : ClojureScript )를 보고 코드 테스트에 투자하는 것이 좋습니다 . 서브 스택의 방법을 읽으십시오아이디어를 얻으려면 .

평화.


답변

수동 보풀 설정을 수행하는 대신 JS 파일 맨 위에 모든 보풀 설정을 포함시킬 수 있습니다.

해당 파일의 모든 전역 변수를 다음과 같이 선언하십시오.

/*global require,dojo,dojoConfig,alert */

다음과 같이 모든 보푸라기 설정을 선언하십시오.

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

희망이 당신을 도울 것입니다 🙂