Analyzing code for hidden errors

Let's suppose that you have the following JavaScript:

// src/Ch01/Ch01_Demo.js
function makePerson(id, name) { return {id, name}; }

A lot of things can go wrong with the preceding code; they are as follows:

• The caller can pass in nulls or undefined values as arguments
• The caller can pass in unintended types of arguments
• The caller can manipulate the returned person object any way they like, for example, they can add or remove properties

In other words, this code doesn't prevent a number of potential errors. In JavaScript, we have linters, such as ESLint (https://eslint.org/), that check for a lot of possible errors, but you have to remember to find them, enable them, and then work around their limitations. A linter can be helpful in various other ways, such as by pointing out the recommended best practices in a coding style. However, linters in JavaScript are often re-purposed to perform static type checking tasks as well; because they offer so much flexibility and need to be configured (in fact, people usually upload their preferred sets of configuration for different styles of programming), there may be large differences in what exactly gets checked across different codebases.