Should I use JSLint or JSHint JavaScript validation

Question

I am currently validating my JavaScript against JSLint and making progress on  it s assisting me to write better JavaScript - in particular in working with the Jquery library   I have now come across JSHint  a fork of JSLint  So I am wondering for web applications  which are very much JavaScript was driven  which is the better or most applicable validation tool to work against      JSLint or JSHint      I want to decide now on a validation mechanism and moving forward  use this for client side validation   And Difference between jshint and jslint  Please explain in single javascript example   Links    jshint-    http   www jshint com  jslint-    http   jslint com

User · Answer

Foreword  Well  that escalated quickly  But decided to pull it through  May this answer be helpful to you and other readers     Code Hinting  While JSLint and JSHint are good tools to use  over the years I ve come to appreciate what my friend  ugly syntax calls      smaller design space    This is a general principle  much like a  zen monk   limiting the choices one has to make  one can be more productive and creative   Therefore my current favourite zero-config JS code style      StandardJS    UPDATE   Flow has improved a lot  With it  you can add types to your JS with will help you prevent a lot of bugs  But it can also stay out of your way  for instance when interfacing untyped JS  Give it a try   Quickstart   TL DR  Add standard as a dependency to you project  npm install --save standard   Then in package json  add the following test script    scripts          test    node modules  bin standard  amp  amp  echo put further tests here       For snazzier output while developing  npm install --global snazzy and run it instead of npm test   Note  Type checking versus Heuristics  My friend when mentioning design space referred to Elm and I encourage you to give that language a try   Why  JS is in fact inspired by LISP  which is a special class of languages  which happens to be untyped  Language such as Elm or Purescript are typed functional programming languages   Type restrict your freedom in order for the compiler to be able to check and guide you when you end up violation the language or your own program s rules  regardless of the size  LOC  of your program   We recently had a junior colleague implement a reactive interface twice  once in Elm  once in React  have a look to get some idea of what I m talking about      Compare Main elm  typed    index js  untyped  no tests     ps  note that the React code is not idiomatic and could be improved   One final remark   the reality is that JS is untyped  Who am I to suggest typed programming to you   See  with JS we are in a different domain  freed from types  we can easily express things that are hard or impossible to give a proper type  which can certainly be an advantage    But without types there is little to keep our programs in check  so we are forced to introduce tests and  to a lesser extend  code styles   I recommend you look at LISP  e g  ClojureScript  for inspiration and invest in testing your codes  Read The way of the substack to get an idea   Peace

User · Answer

Well  Instead of doing manual lint settings we can include all the lint settings at the top of our JS file itself e g   Declare all the global var in that file like      global require dojo dojoConfig alert      Declare all the lint settings like      jslint browser true sloppy true nomen true unparam true plusplus true indent 4      Hope this will help you

User · Answer

I had the same question a couple of weeks ago and was evaluating both JSLint and JSHint   Contrary to the answers in this question  my conclusion was not      By all means use JSLint    Or      If you re looking for a very high standard for yourself or team  JSLint    As you can configure almost the same rules in JSHint as in JSLint  So I would argue that there s not much difference in the rules you could achieve   So the reasons to choose one over another are more political than technical   We ve finally decided to go with JSHint because of the following reasons    Seems to be more configurable that JSLint  Looks definitely more community-driven rather than one-man-show  no matter how cool The Man is   JSHint matched our code style OOTB better that JSLint

User · Answer

There is an another mature and actively developed  player  on the javascript linting front - ESLint      ESLint is a tool for identifying and reporting on patterns found in   ECMAScript JavaScript code  In many ways  it is similar to JSLint and   JSHint with a few exceptions          ESLint uses Esprima for JavaScript parsing      ESLint uses an AST to evaluate patterns in code     ESLint is completely pluggable  every   single rule is a plugin and you can add more at runtime       What really matters here is that it is extendable via custom plugins rules  There are already multiple plugins written for different purposes  Among others  there are    eslint-plugin-angular  enforces some of the guidelines from John Papa s Angular Style Guide  eslint-plugin-jasmine eslint-plugin-backbone   And  of course  you can use your build tool of choice to run ESLint    grunt-eslint gulp-eslint

User · Answer

I d make a third suggestion  Google Closure Compiler  and also the Closure Linter    You can try it out online here      The Closure Compiler is a tool for making JavaScript download and run faster  It is a true compiler for JavaScript  Instead of compiling from a source language to machine code  it compiles from JavaScript to better JavaScript  It parses your JavaScript  analyzes it  removes dead code and rewrites and minimizes what s left  It also checks syntax  variable references  and types  and warns about common JavaScript pitfalls

User · Answer

EDIT  This answer has been edited  I m leaving the original answer below for context  otherwise the comments wouldn t make sense    When this question was originally asked  JSLint was the main linting tool for JavaScript  JSHint was a new fork of JSLint  but had not yet diverged much from the original   Since then  JSLint has remained pretty much static  while JSHint has changed a great deal - it has thrown away many of JSLint s more antagonistic rules  has added a whole load of new rules  and has generally become more flexible  Also  another tool ESLint is now available  which is even more flexible and has more rule options   In my original answer  I said that you should not force yourself to stick to JSLint s rules  as long as you understood why it was throwing a warning  you could make a judgement for yourself about whether to change the code to resolve the warning or not   With the ultra-strict ruleset of JSLint from 2011  this was reasonable advice -- I ve seen very few JavaScript codesets that could pass a JSLint test  However with the more pragmatic rules available in today s JSHint and ESLint tools  it is a much more realistic proposition to try to get your code passing through them with zero warnings   There may still occasionally be cases where a linter will complain about something that you ve done intentionally -- for example  you know that you should always use     but just this one time you have a good reason to use     But even then  with ESLint you have the option to specify eslint-disable around the line in question so you can still have a passing lint test with zero warnings  with the rest of your code obeying the rule   just don t do that kind of thing too often       ORIGINAL ANSWER FOLLOWS   By all means use JSLint  But don t get hung up on the results and on fixing everything that it warns about  It will help you improve your code  and it will help you find potential bugs  but not everything that JSLint complains about turns out to be a real problem  so don t feel like you have to complete the process with zero warnings   Pretty much any Javascript code with any significant length or complexity will produce warnings in JSLint  no matter how well written it is  If you don t believe me  try running some popular libraries like JQuery through it   Some JSLint warnings are more valuable than others  learn which ones to watch out for  and which ones are less important  Every warning should be considered  but don t feel obliged to fix your code to clear any given warning  it s perfectly okay to look at the code and decide you re happy with it  there are times when things that JSlint doesn t like are actually the right thing to do

User · Answer

tl dr takeaway    If you re looking for a very high standard for yourself or team  JSLint  But its not necessarily THE standard  just A standard  some of which comes to us dogmatically from a javascript god named Doug Crockford  If you want to be a bit more flexible  or have some old pros on your team that don t buy into JSLint s opinions  or are going back and forth between JS and other C-family languages on a regular basis  try JSHint   long version   The reasoning behind the fork explains pretty well why JSHint exists    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   So I guess the idea is that it s  community-driven  rather than Crockford-driven  In practicality  JSHint is generally a bit more lenient  or at least configurable or agnostic  on a few stylistic and minor syntactical  opinions  that JSLint is a stickler on    As an example  if you think both the A and B below are fine  or if you want to write code with one or more of the aspects of A that aren t available in B  JSHint is for you  If you think B is the only correct option    JSLint  I m sure there are other differences  but this highlights a few     A  Passes JSHint out of the box - fails JSLint   function        use strict     var x 0  y 2    function add val1  val2       return val1   val2        var z    for  var i 0  i lt 2  i         z   add y  x i               B  Passes Both JSHint and JSLint   function           use strict       var x   0  y   2  i  z      function add val1  val2           return val1   val2            for  i   0  i  lt  2  i    1            z   add y  x   i                 Personally I find JSLint code very nice to look at  and the only hard features of it that I disagree with are its hatred of more than one var declaration in a function and of for-loop var i   0 declarations  and some of the whitespace enforcements for function declarations    A few of the whitespace things that JSLint enforces  I find to be not necessarily bad  but out of sync with some pretty standard whitespace conventions for other languages in the family  C  Java  Python  etc      which are often followed as conventions in Javascript as well  Since I m writing in various of these languages throughout the day  and working with team members who don t like Lint-style whitespace in our code  I find JSHint to be a good balance   It catches stuff that s a legitimate bug or really bad form  but doesn t bark at me like JSLint does  sometimes  in ways I can t disable  for the stylistic opinions or syntactic nitpicks that I don t care for     A lot of good libraries aren t Lint able  which to me demonstrates that there s some truth to the idea that some of JSLint is simply just about pushing 1 version of  good code   which is  indeed  good code    But then again  the same libraries  or other good ones  probably aren t Hint able either  so  touch

User · Answer

There is also an another actively developed alternative - JSCS     JavaScript Code Style      JSCS is a code style linter for programmatically enforcing your style   guide  You can configure JSCS for your project in detail using over   150 validation rules  including presets from popular style guides like   jQuery  Airbnb  Google  and more    It comes with multiple presets that you can choose from by simply specifying the preset in the  jscsrc configuration file and customize it - override  enable or disable any rules          preset    jquery        requireCurlyBraces   null     There are also plugins and extensions built for popular editors   Also see    Perfect code  zero effort

[javascript] Should I use JSLint or JSHint JavaScript validation?

Code Hinting

Quickstart / TL;DR

Note: Type checking versus Heuristics

One final remark,

Examples related to javascript

Examples related to jslint

Examples related to jshint