Skip to content

Install JSHint#54

Open
568cats wants to merge 1 commit intomainfrom
tools/jshint
Open

Install JSHint#54
568cats wants to merge 1 commit intomainfrom
tools/jshint

Conversation

@568cats
Copy link
Copy Markdown

@568cats 568cats commented Mar 12, 2026

Installed JSHint, which is a static analysis tool.

Tool Analysis

This is a static analysis tool called JSHint. In brief, JSHint performs static checks to help improve/fix code syntax and type errors, among others. The docs can be found here. In addition to installing JSHint to your project directly, you can also paste code here to perform the static checks.

JSHint is extremely customizable. Using various "options," you can specify what rules you want the tool to check for. For instance, by specifying undef: true, JSHint will check if the program contains an undefined or unused variables. Other examples include: leanswitch, which looks at switch statements; maxdepth, which lets you limit the maximum nesting in your code; and maxparams, which limits the number of parameters allowed in a function to control code complexity. These options can be set in the global configuration file, or in individual code files if you want to fine-tune the options to a specific use-case. Moreover, by adding JSHint comments in individual files, you can specify if there are lines that JSHint should ignore when scanning your code.

JSHint should be integrated into the development process such that programmers are constantly using it to check for errors. If you use this tool to analyze your code after making a few changes, it will allow you to catch and fix errors earlier on in the development process. Moreover, JSHint should be run on the entire program before the code is deployed so that any final errors are fixed before deployment.

Regarding false positives/false negatives, JSHint will flag some false positive results. For instance, when I ran JSHint on NodeBB, one of the flags I got was confusing use of '!' on this line: if (!(parseInt(uid, 10) > 0)) { return; }. However, it is pretty clear what the usage of ! is meant to represent on this line. If you wanted to stop this flag from appearing, you would have to remove the corresponding option from the config file. Note that doing so may in turn prevent future true positive errors relating to this issue from being caught.

Usage

To use the tool, run npm run jshint

The checks that the tool performs are listed in the .jshintrc file. Currently, I added only a few checks, but more checks can/should be added for a better analysis.

When run currently, the following output is obtained: test-jshint.txt

In the above file, we can see that there are 48 errors based on the current checks performed.

Pros & Cons

One interesting aspect of JSHint is that we can customize the checks it performs by adding/removing them in the .jshintrc file. Currently, I have set up the following:

image

This specifies the version of ECMAScript/JavaScript to allow, allows Node.js, and catches variables that are undefined or unused. For instance, when I add "curly": true, JSHint checks whether curly braces exist around blocks of code such as loops and functions. When I run this, we get more errors (65), and a list of where these errors occur.

image

Pros

  • The .jshintrc file allows for a lot of customization, allowing you to prioritize what tests you want to perform and what you want to enforce in your code files.
  • Checks for safety--some of the options JSHint can check for are identifying undefined variables, which can help catch memory access problems

Cons

  • Having a lot of customization means that you can relax your rules such that JSHint finds less errors, so you get better results without checking if your code is safe/correct
  • Many options check stylistic choices, such as the usage of curly brackets, equality, unused variables, redundant switch statements. These can declutter your code, but do not actually test for correctness.

Steps I Took

Installed JSHint with npm install --save-dev jshint

Created a .jshintrc file, which lists all the rules that should be checked by the tool.

Updated packages.json so the script npm run jshint runs JSHint

@568cats
Copy link
Copy Markdown
Author

568cats commented Mar 20, 2026

Added tool analysis here as well:

Tool Analysis

This is a static analysis tool called JSHint. In brief, JSHint performs static checks to help improve/fix code syntax and type errors, among others. The docs can be found here. In addition to installing JSHint to your project directly, you can also paste code here to perform the static checks.

JSHint is extremely customizable. Using various "options," you can specify what rules you want the tool to check for. For instance, by specifying undef: true, JSHint will check if the program contains an undefined or unused variables. Other examples include: leanswitch, which looks at switch statements; maxdepth, which lets you limit the maximum nesting in your code; and maxparams, which limits the number of parameters allowed in a function to control code complexity. These options can be set in the global configuration file, or in individual code files if you want to fine-tune the options to a specific use-case. Moreover, by adding JSHint comments in individual files, you can specify if there are lines that JSHint should ignore when scanning your code.

JSHint should be integrated into the development process such that programmers are constantly using it to check for errors. If you use this tool to analyze your code after making a few changes, it will allow you to catch and fix errors earlier on in the development process. Moreover, JSHint should be run on the entire program before the code is deployed so that any final errors are fixed before deployment.

Regarding false positives/false negatives, JSHint will flag some false positive results. For instance, when I ran JSHint on NodeBB, one of the flags I got was confusing use of '!' on this line: if (!(parseInt(uid, 10) > 0)) { return; }. However, it is pretty clear what the usage of ! is meant to represent on this line. If you wanted to stop this flag from appearing, you would have to remove the corresponding option from the config file. Note that doing so may in turn prevent future true positive errors relating to this issue from being caught.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant