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

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

• JSLint 또는 JSHint?

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

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

연결:

1. jshint - http: //www.jshint.com/

2. jslint - http: //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 플러그인 각도 ( John Papa의 앵귤러 스타일 안내서의 일부 지침을 시행 )
• eslint-plugin-jasmine
• eslint-plugin-backbone

물론 선택한 빌드 도구를 사용하여 실행할 수 있습니다. 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 */

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

JSCS (JavaScript Code Style) 라는 또 다른 적극적으로 개발 된 대안이 있습니다 .

JSCS는 프로그래밍 방식으로 스타일 가이드를 적용하기위한 코드 스타일 린터입니다. jQuery, Airbnb, Google 등과 같은 인기있는 스타일 가이드의 사전 설정을 포함하여 150 개가 넘는 유효성 검사 규칙을 사용하여 프로젝트에 대해 JSCS를 세부적으로 구성 할 수 있습니다.

구성 파일 에서 단순히를 지정 하고 사용자 정의하여 규칙을 재정의, 활성화 또는 비활성화 하여 선택할 수 있는 여러 사전 설정 이 제공됩니다 .preset.jscsrc

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

인기있는 편집자를 위해 빌드 된 플러그인과 확장 기능도 있습니다.

참조 :

• 완벽한 코드, 제로 노력