Retailer website example

```javascript Bad theme={null}

``` ```javascript Fix theme={null}

A blooming tulip ```

Variables declared with \`var have the special property that regardless of where they’re declared in a function they "float" to the top of the function and are available for use even before they’re declared. That makes scoping confusing, especially for new coders.

To keep confusion to a minimum, var\` declarations should happen before they are used for the first time.

```javascript Bad theme={null} var x = 1; function fun(){ alert(x); // Noncompliant as x is declared later in the same scope if(something) { var x = 42; // Declaration in function scope (not block scope!) shadows global variable } } fun(); // Unexpectedly alerts "undefined" instead of "1" ``` ```javascript Fix theme={null} var x = 1; function fun() { print(x); if (something) { x = 42; } } fun(); // Print "1" ```

The value of this depends on which context it appears:

Function: The value of this will depend on how a function was called. The value of this is not always the object that has the function as an own property, but the object that is used to call the function. The methods Function.prototype.call(), Function.prototype.apply(), or Reflect.apply() can be used to explicitly set the value of this. Is it also possible to create a new function with a specific value of this that doesn’t change regardless of how the function is called with Function.prototype.bind(). In non-strict mode, this will always be an object and will default to globalThis if set to undefined or null.
Arrow function: The value of this will be the same as the enclosing context. Arrow functions will not create a new this binding. When invoking arrow functions using call(), bind(), or apply(), the thisArg parameter is ignored.
Class: Class methods behave like methods in other objects: the this value is the object that the method was accessed on. If the method is not transferred to another object, this is generally an instance of the class. However, for static methods, the value of this is the class instead of the instance.
Global: outside of any functions or classes (also inside blocks or arrow functions defined in the global scope), the value of this depends on what execution context the script runs in.

When a function is called without an explicit object context, the this keyword refers to the global object. This also applies when it is used outside of an object or function. The global this object refers to the global context in which the JavaScript code is executed. This can cause problems when the code is executed in different contexts, such as in a browser or in a Node.js environment, where the global object is different. Such uses could confuse maintainers as the actual value depends on the execution context, and it can be unclear what object the \`this keyword is referring to.

In JavaScript’s "strict mode", using this in the global context will always be undefined\`.

```javascript Bad theme={null} this.foo = 1; // Noncompliant: 'this' refers to global 'this' console.log(this.foo); // Noncompliant: 'this' refers to global 'this' function MyObj() { this.foo = 1; // Compliant } MyObj.func1 = function() { if (this.foo === 1) { // Compliant // ... } } ``` ```javascript Fix theme={null} foo = 1; console.log(foo); function MyObj() { this.foo = 1; } MyObj.func1 = function() { if (this.foo === 1) { // ... } } ```

User-defined JSX components should use Pascal case because it is a widely accepted convention in the React community. Using Pascal case for component names helps to distinguish them from HTML elements and built-in React components, which are typically written in lowercase. It also improves code readability and makes it easier to differentiate between components and regular HTML tags.

Additionally, adhering to this convention ensures consistency and makes it easier for other developers to understand and work with your code. It is considered a best practice in React development and is recommended by the official React documentation.

```javascript Bad theme={null} ``` ```javascript Fix theme={null} ```

Including content in your site from an untrusted source can expose your users to attackers and even compromise your own site. For that reason, this rule raises an issue for each non-relative URL.

```javascript Bad theme={null} function include(url) { var s = document.createElement("script"); s.setAttribute("type", "text/javascript"); s.setAttribute("src", url); document.body.appendChild(s); } include("http://hackers.com/steal.js") // Noncompliant ``` ```javascript Fix theme={null} ```

The use of comparison operators (\<, \<=, >=, >) with strings is not likely to yield the expected results. Make sure the intention was to compare strings and not numbers.

```javascript Bad theme={null} var appleNumber = "123"; var orangeNumber = "45"; if (appleNumber < orangeNumber) { // Noncompliant, this condition is true alert("There are more oranges"); } ``` ```javascript Fix theme={null} var appleNumber = "123"; var orangeNumber = "45"; if (Number(appleNumber) < Number(orangeNumber)) { alert("There are more oranges"); } ```

The unary operators + and - can be used to convert some value types to numeric values. But not every value can be converted to a Number type; use it with an object, and result will be NaN (Not A Number). This can be confusing to maintainers.

```javascript Bad theme={null} var obj = {x : 1}; doSomethingWithNumber(+obj); // Noncompliant function foo(){ return 1; } doSomethingWithNumber(-foo); // Noncompliant ``` ```javascript Fix theme={null} var obj = {x : 1}; doSomethingWithNumber(+obj.x); function foo(){ return 1; } doSomethingWithNumber(-foo()); var str = '42'; doSomethingWithNumber(+str); ```

Even if your document is arranged in many layers, you don’t have to step through those layers explicitly to select an element. In fact, it’s more efficiently to skim over some of those layers rather than making the JQuery selector engine explicitly step through each one.

```javascript Bad theme={null} $( "div.data table.attendees td.campbell" ); // Noncompliant; too many selectors. There's no need to trace through each layer of the structure ``` ```javascript Fix theme={null} $( ".data td.campbell"); ```

Template strings allow developers to embed variables or expressions in strings using template literals, instead of string concatenation. This is done by using expressions like \$\{variable} in a string between two back-ticks (\`). However, when used in a regular string literal (between double or single quotes) the template will not be evaluated and will be used as a literal, which is probably not what was intended.

```javascript Bad theme={null} console.log("Today is ${date}"); // Noncompliant ``` ```javascript Fix theme={null} console.log(`Today is ${date}`); ```

Internet Explorer offers a way to change the JavaScript code at runtime using conditional comments (activated by a @cc\_on statement found in a comment). Using this preprocessing feature decreases readability and maintainability, and can hinder automated tools. What’s more, it is specific to Internet Explorer and won’t work for other browsers.

Most of the time, using those conditional comments can be easily avoided with some refactoring - using modern cross-browsers JavaScript frameworks and libraries.

```javascript Bad theme={null} /*@cc_on @if (@_jscript_version >= 5.5) document.write("You are using IE5.5 or newer"); @else document.write("You are using IE5 or older"); @end @*/ ``` ```javascript Fix theme={null} ```

In JavaScript, object shorthand syntax is a more concise way to define properties on objects. It was introduced to make object literals more readable and expressive.

In the shorthand syntax, if a variable exists in the scope with the same name as the object key you’re defining, you can omit the key-value pair and just write the variable name. The interpreter will automatically understand that the key and the variable are linked.

Using object shorthand syntax can make your code cleaner and easier to read. It can also reduce the chance of making errors, as you don’t have to repeat yourself by writing the variable name twice.

```javascript Bad theme={null} let a = 1; let myObj = { a : a, // Noncompliant fun: function () { // Noncompliant //... } } ``` ```javascript Fix theme={null} let a = 1; let myObj = { a, fun () { //... } } ```

Session storage and local storage are HTML 5 features which allow developers to easily store megabytes of data client-side, as opposed to the 4Kb cookies can accommodate. While useful to speed applications up on the client side, it can be dangerous to store sensitive information this way because the data is not encrypted by default and any script on the page may access it.

This rule raises an issue when the localStorage and sessionStorage API’s are used.

```javascript Bad theme={null} localStorage.setItem("login", login); // Noncompliant sessionStorage.setItem("sessionId", sessionId); // Noncompliant ``` ```javascript Fix theme={null} ```

In JavaScript, \`arguments is a built-in array-like object automatically available within the scope of all non-arrow functions. It allows you to access the arguments the function was called with, even if the number of arguments passed during the function call does not match the number declared in the function signature. arguments has entries for each argument, with the first entry’s index at 0.

The arguments object has two deprecated properties called arguments.caller and arguments.callee, which were used to refer to functions involved in the function invocation chain:

The arguments.callee property contains the currently executing function that the arguments belong to.
The arguments.caller property returns the function that invoked the currently executing function. It was replaced by Function.prototype.caller, which provides the same functionality.

Both arguments.caller and arguments.callee are non-standard, deprecated, and leak stack information, which poses security risks and severely limits the possibility of optimizations.

Accessing arguments.callee, Function.prototype.caller and Function.prototype.arguments in strict mode will throw a TypeError\`.

```javascript Bad theme={null} function whoCalled() { if (arguments.caller == null) //Noncompliant console.log('I was called from the global scope.'); else console.log(arguments.caller + ' called me!'); // Noncompliant console.log(whoCalled.caller); // Noncompliant console.log(whoCalled.arguments); // Noncompliant } ``` ```javascript Fix theme={null} ```

In a Zen-like manner, \`NaN isn’t equal to anything, even itself. So comparisons (>, \<, >=, \<=) where one operand is NaN or evaluates to NaN always return false. Specifically, undefined and objects that cannot be converted to numbers evaluate to NaN when used in numerical comparisons.

This rule raises an issue when there is at least one path through the code where one of the operands to a comparison is NaN, undefined or an Object\` which cannot be converted to a number.

```javascript Bad theme={null} var x; // x is currently "undefined" if (someCondition()) { x = 42; } if (42 > x) { // Noncompliant; "x" might still be "undefined" doSomething(); } var obj = {prop: 42}; if (obj > 24) { // Noncompliant doSomething(); } ``` ```javascript Fix theme={null} var x; if (someCondition()) { x = 42; } else { x = foo(); } if (42 > x) { doSomething(); } var obj = {prop: 42}; if (obj.prop > 24) { doSomething(); } ```

TypeScript supports type inference, a mechanism that automatically infers the type of a variable based on its initial value. This means that if you initialize a variable with a particular value, TypeScript will assume that this variable should always hold that type of value.

Unnecessarily verbose declarations and initializations make it harder to read the code and should be simplified. Therefore, type annotations should be omitted from variable and parameter declarations when they can be easily inferred from the initialized or defaulted value.

```javascript Bad theme={null} const n: number = 1; // Noncompliant, "number" can be omitted function foo(s: string = "") {} // Noncompliant, "string" can be omitted class Bar { b: boolean = true; // Noncompliant, "boolean" can be omitted } ``` ```javascript Fix theme={null} const n = 1; function foo(s = "") {} class Bar { b = true; } ```

Shared naming conventions allow teams to collaborate efficiently.

This rule raises an issue when a function or a method name does not match a provided regular expression.

For example, with the default regular expression ^\[a-z]\[a-zA-Z0-9]\*\$, the function:

```javascript Bad theme={null} function DoSomething(){...} // Noncompliant ``` ```javascript Fix theme={null} function doSomething(){...} ```

Before ECMAScript 2015, module management had to be ad-hoc or provided by 3rd-party libraries such as Node.js, Webpack, or RequireJS. Fortunately, ES2015, provides language-standard mechanisms for module management, import and export, and older usages should be converted.

```javascript Bad theme={null} // circle.js exports.area = function (r) { return PI * r * r; }; // foo.js define(["./cart", "./horse"], function(cart, horse) { // Noncompliant // ... }); // bar.js const circle = require('./circle.js'); // Noncompliant ``` ```javascript Fix theme={null} // circle.js let area = function (r) { return PI * r * r; } export default area; // foo.js import cart from "./cart.js"; import horse from "./horse.js"; // bar.js import circle from "./circle.js" ```

Assertions are statements that check whether certain conditions are true. They are used to validate that the actual results of a code snippet match the expected outcomes. By using assertions, developers can ensure that their code behaves as intended and identify potential bugs or issues early in the development process.

When the unit test is executed, the assertions are evaluated. If all the assertions in the test pass, it means the unit is functioning correctly for that specific set of inputs. If any of the assertions fail, it indicates that there is a problem with the unit’s implementation, and the test case helps identify the issue.

It is not good enough to test if an exception is raised, without checking which exception it is. Such tests will not be able to differentiate the expected exception from an unexpected one.

This rule raises an issue in the following cases:

When an asynchronous Mocha test calls the \`done() callback, without parameters, in a catch block, and there is no reference to the caught exception in this block. Either the error should be passed to done() or the exception should be checked further.
When Chai assertions are used to test if a function throws any exception, or an exception of type Error without checking the message.
When Chai assertions are used to test if a function does not throw an exception of type Error\` without checking the message.

This rule doesn’t raise an issue when an assertion is negated. In such a case, the exception doesn’t need to be specific.

```javascript Bad theme={null} const expect = require("chai").expect; const fs = require("fs"); describe("exceptions are not tested properly", function() { const funcThrows = function () { throw new TypeError('What is this type?'); }; const funcNoThrow = function () { /*noop*/ }; it("forgot to pass the error to 'done()'", function(done) { fs.readFile("/etc/zshrc", 'utf8', function(err, data) { try { expect(data).to.match(/some expected string/); } catch (e) { done(); // Noncompliant: either the exception should be passed to done(e), or the exception should be tested further. } }); }); it("does not 'expect' a specific exception", function() { expect(funcThrows).to.throw(); // Noncompliant: the exception should be tested. expect(funcThrows).to.throw(Error); // Noncompliant: the exception should be tested further. }); }); ``` ```javascript Fix theme={null} const expect = require("chai").expect; const { AssertionError } = require('chai'); const fs = require("fs"); describe("exceptions are tested properly", function() { const funcThrows = function () { throw new TypeError('What is this type?'); }; const funcNoThrow = function () { /*noop*/ }; it("did not forget to pass the error to 'done()'", function(done) { fs.readFile("/etc/zshrc", 'utf8', function(err, data) { try { expect(data).to.match(/some expected string/); } catch (e) { expect(e).to.be.an.instanceof(AssertionError); done(); } }); }); it("does 'expect' a specific exception", function() { expect(funcThrows).to.throw(TypeError); expect(funcNoThrow).to.not.throw(Error, /My error message/); }); }); ```

In Node.js, it’s possible to import modules by specifying an absolute path, such as /lib/foo/bar.js. However, this approach can limit the portability of your code, as it becomes tied to your computer’s file system. This could potentially lead to problems when the code is distributed, for instance, via NPM packages. Therefore, it’s advisable to use relative paths or module names for importing modules to enhance the portability and compatibility of your code across different systems.

```javascript Bad theme={null} import { foo } from '/home/project/api/bar.js'; ``` ```javascript Fix theme={null} import { foo } from '../api/bar.js'; ```

Ternary operator should not be used to select between two boolean values, or instead of a logical OR operation. Ternary expressions are often difficult to read, so if a simpler syntax exists, it should be used instead of a ternary expression. This happens when

the expression returns two boolean values

```javascript Bad theme={null} let isGood = value > 0 ? true : false; // Non-compliant, replace with value > 0 let isBad = value > 0 ? false : true; // Non-compliant, replace with !(value > 0) ``` ```javascript Fix theme={null} let a = x ? x : y; // Non-compliant, replace with x || y ```

Optional chaining allows to safely access nested properties or methods of an object without having to check for the existence of each intermediate property manually. It provides a concise and safe way to access nested properties or methods without having to write complex and error-prone null/undefined checks.

This rule flags logical operations that can be safely replaced with the ?. optional chaining operator.

```javascript Bad theme={null} function foo(obj, arr, fn) { if (obj && obj.value) {} if (arr && arr[0]) {} if (fn && fn(42)) {} } ``` ```javascript Fix theme={null} function foo(obj, arr, fn) { if (obj?.value) {} if (arr?.[0]) {} if (fn?.(42)) {} } ```

When using regular expressions, a capturing group provides extra information about the matched pattern. Named groups will store the matched contents on the groups property of the returned matches.

```javascript Bad theme={null} const regex = /(?[0-9]{2})\/(?[0-9]{2})/; const { groups: {month, year} } = regex.exec("01/02"); // month is '01', year is '02' ``` ```javascript Fix theme={null} const score = "14:1"; const scorePattern = /(?[0-9]+):(?[0-9]+)/; // Noncompliant - named groups are never used if (scorePattern.exec(score)) { checkScore(score); } ```

In TypeScript, a type alias is a way to give a name to a specific type. It allows you to create a new name for an existing type, making your code more expressive and readable. This is especially useful when you are working with complex or lengthy types that you use frequently.

Type aliases should be preferred over complex types like unions or intersections for several reasons:

Type aliases can make your code more readable and maintainable by giving meaningful names to complex types. When you use a type alias, it becomes clear what the type represents, making it easier for other developers (including your future self) to understand the code.
Type aliases promote code reusability. When you define a type alias for a complex type, you can use that alias in multiple places throughout your codebase, reducing duplication and promoting consistency.
Type aliases allow you to abstract away the underlying complexity of types. This promotes encapsulation by hiding implementation details behind a well-named alias, allowing you to change the underlying type in the future without affecting the code that uses the alias.
If you need to modify a complex type, using a type alias means you only need to change the type definition in one place. This change will automatically apply to all usages of the alias.
Type aliases communicate the intent of the type, making it easier for other developers to understand what the type represents. Complex unions and intersections, on the other hand, might require additional comments or documentation to explain their purpose.
Using type aliases can help you avoid excessive nesting of complex types. Nested unions and intersections can quickly become hard to read and maintain, and type aliases can simplify the type definitions.

This rule enforces the rule of three for code refactoring and reports unions and intersections with three or more constituents appearing at least three times in the codebase.

```javascript Bad theme={null} function foo(x: string | null | number) { // Noncompliant: The union has three constituents and is duplicated three times in the code /* ... */ } let bar: string | null | number = /* ... */; function baz(): string | null | number { /* ... */ } ``` ```javascript Fix theme={null} type MyType = string | null | number; function foo(x: MyType) { /* ... */ } let bar: MyType = /* ... */; function baz(): MyType { /* ... */ } ```

Creating an object without assigning it to a variable or using it in any function means the object is essentially created for no reason and may be dropped immediately without being used. Most of the time, this is due to a missing piece of code and could lead to an unexpected behavior.

If it’s intended because the constructor has side effects, that side effect should be moved into a separate method and called directly. This can help to improve the performance and readability of the code.

```javascript Bad theme={null} new MyConstructor(); // Noncompliant: object may be dropped ``` ```javascript Fix theme={null} let something = new MyConstructor(); ```

This rule enforces the idea to use ES6 style to create React Component instead of the ES5 way.

```javascript Bad theme={null} var Rating = createReactClass({ // Noncompliant [...] }); ``` ```javascript Fix theme={null} export default class Rating extends React.Component { // Compliant [...] } ```

Unlike strongly typed languages, JavaScript does not enforce a return type on a function. This means that different paths through a function can return different types of values.

Returning different types from a function can make the code less readable and harder to understand. Maintainers may have to spend more time figuring out how the function works and what it returns. Additionally, it can be harder to ensure that the code is free of type-related errors.

```javascript Bad theme={null} function foo(a) { // Noncompliant: function returns 'boolean' or 'number' if (a === 1) { return true; } return 3; } ``` ```javascript Fix theme={null} function foo(a) { if (a === 1) { return true; } return false; } ```

In TypeScript, casts and non-null assertions are two mechanisms used to inform the TypeScript compiler about the intended types of variables, expressions, or values in the code. They are used to help the compiler understand the types more accurately and to handle certain situations where type inference might not be sufficient:

A type assertion tells the compiler to treat the value as the specified type, even if the compiler’s type inference suggests a different type.
A non-null assertion is a way to tell the TypeScript compiler explicitly that you are certain that a variable will not be \`null or undefined, and you want to access its properties or methods without any null checks.

However, a redundant cast occurs when you perform a type assertion that is not needed because the compiler already knows the type based on the context or explicit type declarations. Similarly, a redundant non-null assertion occurs when you use the non-null assertion operator ! to assert that a variable is not null or undefined\`, but the compiler already knows that based on the context.

Both redundant casts and redundant non-null assertions should be avoided in TypeScript code, as they add unnecessary noise, clutter the code, and lead to confusion.

```javascript Bad theme={null} function getName(x?: string | Person) { if (x) { console.log("Getting name for " + x!); // Noncompliant: 'x' is known to be defined here if (typeof x === "string") { return (x as string); // Noncompliant: 'x' is known to be a string here } else { return (x as Person).name; // Noncompliant: 'x' is defined and not a string, thus a 'Person' here } } return "NoName"; } ``` ```javascript Fix theme={null} function getName(x?: string | Person) { if (x) { console.log("Getting name for " + x); if (typeof x === "string") { return x; } else { return x.name; } } return "NoName"; } ```

Any variable or function declared in the global scope implicitly becomes attached to the global object (the window object in a browser environment). To make it explicit this variable or function should be a property of window. When it is meant to be used just locally, it should be declared with the const or let keywords (since ECMAScript 2015) or within an Immediately-Invoked Function Expression (IIFE).

This rule should not be activated when modules are used.

```javascript Bad theme={null} var myVar = 42; // Noncompliant function myFunc() { } // Noncompliant ``` ```javascript Fix theme={null} window.myVar = 42; window.myFunc = function() { }; ```

\`for...of statements are used to iterate over the values of an iterable object. Iterables are objects implementing the @@iterator method, which returns an object conforming to the iterator protocol. JavaScript provides many built-in iterables that can and should be used with this looping statement.

The use of the for...of statement is recommended over the for\` statement when iterating through iterable objects as simplifies the syntax and eliminates the need for a counter variable.

```javascript Bad theme={null} const arr = [4, 3, 2, 1]; for (let i = 0; i < arr.length; i++) { // Noncompliant: arr is an iterable object console.log(arr[i]); } ``` ```javascript Fix theme={null} const arr = [4, 3, 2, 1]; for (let value of arr) { console.log(value); } ```

A sparse array is an array in which the elements do not occupy a contiguous range of indices. In other words, there are gaps (or "holes") between the elements in the array, where some indices have no corresponding value assigned to them.

Including an extra comma in an array literal signifies an empty slot in the array, thus creating a sparse array. An empty slot is not the same as a slot filled with the undefined value. In some operations, empty slots behave as if they are filled with undefined but are skipped in others.

While this is a well-defined behavior, it can be misleading and raises suspicions about the original intent: an extra comma was intentionally inserted, or perhaps the developer meant to insert the missing value but forgot.

```javascript Bad theme={null} let a = [1, , 3, 6, 9]; // Noncompliant: Extra comma maybe denoting an oversight ``` ```javascript Fix theme={null} let a = [1, 3, 6, 9]; ```

Doing an operation on a string without using the result of the operation is useless and is certainly due to a misunderstanding.

```javascript Bad theme={null} var str = "..." str.toUpperCase(); // Noncompliant ``` ```javascript Fix theme={null} var str = "..." str = str.toUpperCase(); ```

Entries in the ASCII table below code 32 are known as control characters or non-printing characters. As they are not common in JavaScript strings, using these invisible characters in regular expressions is most likely a mistake.

```javascript Bad theme={null} const pattern1 = /\x1a/; // Noncompliant: 1a (23 base 10) is less than 32 const pattern2 = new RegExp('\x1a'); // Noncompliant: 1a (23 base 10) is less than 32 ``` ```javascript Fix theme={null} const pattern1 = /\x20/; const pattern2 = new RegExp('\x20'); ```

In TypeScript, unions and intersections are used to combine multiple types into a single type, allowing you to create more flexible and powerful type definitions.

A union type is represented using the pipe symbol \`|. It allows you to declare a variable or parameter that can hold values of different types. The variable can be assigned a value of any type listed in the union.
An intersection type is represented using the ampersand symbol &\`. It allows you to combine multiple types into a single type that includes all the properties and methods from each type.

Having duplicated constituents in TypeScript unions and intersections can lead to undesirable behavior and potential issues in your code. TypeScript’s type system aims to provide a strong and sound static type checking to catch errors during development and improve code reliability. Including duplicate constituents in unions or intersections can make the type definitions unnecessarily verbose and redundant. This makes the code harder to read and maintain.

```javascript Bad theme={null} function padLeft(value: string, padding: string | number | string) { // Noncompliant: 'string' type is used twice in a union type declaration // ... } function extend(p : Person) : Person & Person & Loggable { // Noncompliant: 'Person' is used twice // ... } ``` ```javascript Fix theme={null} function padLeft(value: string, padding: string | number | boolean) { // ... } function extend(p : Person) : Person & Loggable { // ... } ```

TypeScript provides the type mechanism to create a type alias, that is, a new name to refer to an existing type. It is a nice feature to improve code readability and can be used as documentation. However, aliasing a primitive type, another alias or everyday types like any or unknown is useless and goes against the idea of readable code. As a result, a reader needs to go through the mental exercise of remembering the underlying type behind the alias and loses track of the code’s primary purpose.

Common types come with relevant names and should be used as they are.

```javascript Bad theme={null} type MyString = string; type MyBoolean = boolean; function isPalindrom(s: MyString): MyBoolean { return s === s.split('').reverse().join(''); } ``` ```javascript Fix theme={null} function isPalindrom(s: string): boolean { return s === s.split('').reverse().join(''); } ```

The nullish coalescing operator ?? allows providing a default value when dealing with null or undefined. It only coalesces when the original value is null or undefined. Therefore, it is safer and shorter than relying upon chaining logical || expressions or testing against null or undefined explicitly.

This rule reports when disjunctions (||) and conditionals (?) can be safely replaced with coalescing (??).

The TSConfig needs to set strictNullChecks to true for the rule to work properly.

```javascript Bad theme={null} function either(x: number | undefined, y: number) { return x || y; } ``` ```javascript Fix theme={null} function either(x: number | undefined, y: number) { return x ?? y; } ```

When using the Backbone.js framework, the array of models inside a collection, \`collection.models, should not be accessed directly. Doing so bypasses the listeners set on the collection and could put your application in a bad state.

Instead, use get, at\` or the underscore methods.

```javascript Bad theme={null} myCollection.models.forEach(function (model) { }); ``` ```javascript Fix theme={null} myCollection.forEach(function (model) { }); ```

TypeScript provides both numeric and string-based enums. Members of enums can be assigned strings, numbers, both, or none, which default to numbers starting from zero. Although it is possble to mix the types of enum member values, it is generally considered confusing and a bad practice.

Enum members should be consistently assigned values of the same type, that is, strings or numbers.

```javascript Bad theme={null} enum Color { Red, // 0 by default Green = 1, Blue = "blue" } ``` ```javascript Fix theme={null} enum Color { Red = "red", Green = "green", Blue = "blue" } ```

When a function has multiple return statements and returns the same value in more than one of them, it can lead to several potential problems:

It can make the code more difficult to understand and maintain, as the reader may be unsure why the same value is being returned multiple times. This can introduce ambiguity and increase the chances of misunderstanding the function’s intent.
The use of multiple return statements with the same value might lead someone to assume that each return corresponds to a distinct case or outcome. However, if they all return the same value, it can be misleading and may indicate an oversight or mistake in the code.
When the function needs to be modified or extended in the future, having multiple identical return statements can make it harder to implement changes correctly across all occurrences. This can introduce bugs and inconsistencies in the codebase.
Code readability is crucial for maintainability and collaboration. Having repetitive return statements can lead to unnecessary code duplication, which should be avoided in favor of creating modular and clean code.

This rule raises an issue when a function contains several return statements that all return the same value.

```javascript Bad theme={null} function f(a, g) { // Noncompliant: 'f' returns 'b' on two different return statements const b = 42; if (a) { g(a); return b; } return b; } ``` ```javascript Fix theme={null} function f(a, g) { const b = 42; if (a) { g(a); } return b; } ```

React props should be read-only because it helps to enforce the principle of immutability in React functional components. By making props read-only, you ensure that the data passed from a parent component to a child component cannot be modified directly by the child component. This helps maintain a clear data flow and prevents unexpected side effects.

If props were mutable, child components could modify the props directly, leading to unpredictable behavior and making it harder to track down bugs. By enforcing read-only props, React promotes a more predictable and maintainable codebase. Additionally, read-only props enable performance optimizations in React’s rendering process by avoiding unnecessary re-renders of components.

Overall, enforcing read-only props in React helps improve code reliability, maintainability, and performance.

```javascript Bad theme={null} interface Props { name: string; } function Welcome(props: Props) { // Noncompliant: The component props are not read-only return

Hello {props.name}

; } ``` ```javascript Fix theme={null} interface Props { name: string; } function Welcome(props: Readonly) { return

Hello {props.name}

; } ```

JavaScript regular expressions provide Unicode character classses and Unicode property escapes for matching characters based on their Unicode values and Unicode properties respectively. When using Unicode property escapes like \p\{Alpha} without the u flag, the regular expression will not match alphabetic characters but rather the '\p\{Alpha}' string literal, which is likely a mistake.

This rules raises an issue when Unicode character classses and Unicode property escapes are used without the u flag.

```javascript Bad theme={null} /\u{1234}/ /\p{Alpha}/ ``` ```javascript Fix theme={null} /\u{1234}/u /\p{Alpha}/u ```

When using the Backbone.js framework, the internal hash containing the model’s state, \`model.attributes, should not be accessed directly. Doing so bypasses the listeners set on the model and could put your application in a bad state.

Instead, you should use set to update, get to read, and \_.clone(model.attributes)\` to obtain a copy.

```javascript Bad theme={null} myModel.attributes.someAttribute = 1; ``` ```javascript Fix theme={null} myModel.set({ someAttribute: 1 }); ```

Parameter properties let you both create and initialize a member in one place, and omit an explicit member declaration and the assignment of the constructor parameter to the member. To use a parameter property, add an accessibility modifier or readonly, or both in front of the constructor parameter.

constructor(readonly name: string, private age: number) \{ // creates 2 initialized members "name" and "age"
        }

While this syntax is very concise it might be confusing for developers who are new to TypeScript.

Shared conventions allow teams to collaborate efficiently. This rule checks that either parameter properties are used everywhere or not at all.

```javascript Bad theme={null} class Person { name: number; constructor(name: string) { this.name = name; // Noncompliant, parameter property can be used } } ``` ```javascript Fix theme={null} class Person { constructor(public name: string) { } } ```

ECMAScript 2015 introduced the ability to extract and assign multiple data points from an object or array simultaneously. This is called "destructuring", and it allows you to condense boilerplate code so you can concentrate on logic.

This rule raises an issue when multiple pieces of data are extracted out of the same object or array and assigned to variables.

```javascript Bad theme={null} function foo (obj1, obj2, array) { var a = obj1.a; // Noncompliant var b = obj1.b; var name = obj2.name; // ignored; there's only one extraction-and-assignment var zero = array[0]; // Noncompliant var one = array[1]; } ``` ```javascript Fix theme={null} function foo (obj1, obj2, array) { var {a, b} = obj1; var {name} = obj2; // this syntax works because var name and property name are the same var [zero, one] = array; } ```

Getters and setters provide a way to enforce encapsulation by providing methods that give controlled access to class fields. However, in classes with multiple fields, it is not unusual that copy and paste is used to quickly create the needed getters and setters, which can result in the wrong field being accessed by a getter or setter.

This rule raises an issue in the following cases:

A setter does not update the field with the corresponding name (if it exists).
A getter:
- does not return any value
- does not access the field with the corresponding name (if it exists).

Underscore prefixes for fields are supported, so setX() can assign a value to \`\_x.

The following type of getters and setters are supported:

getX() and setX()\`

```javascript Bad theme={null} class A { #y: number = 0; setY(val: number) { // Noncompliant: field '#y' is not updated } } ``` ```javascript Fix theme={null} class A { #y: number = 0; setY(val: number) { this.#y = val; } } ```

The contract and expectation of a get function is that it will return something. Failing to return a value on all paths is surely an error.

```javascript Bad theme={null} var x = { _prop : "foo", get prop(){ // Noncompliant console.log("prop getter"); } } x.prop; // returns undefined ``` ```javascript Fix theme={null} var x = { _prop : "foo", get prop(){ console.log("prop getter"); return _prop; } } x.prop; // returns "foo" ```

Operator precedence determines the order in which different operators are evaluated when an expression contains multiple ones. It helps determine how the expression is parsed and executed. JavaScript follows a specific set of rules to determine operator precedence.

Not being aware of JavaScript’s operator precedence rules can lead to unexpected and potentially incorrect results when evaluating expressions. This is common when misapplying the logical negation operator (\`!). For instance, consider the difference between !key in dict and !(key in dict). The first looks for a boolean value (!key) in dict, and the other looks for a string and inverts the result. The same applies for !obj instanceof SomeClass.

This rule raises an issue when the left operand of an in or instanceof operator is negated with !\`.

```javascript Bad theme={null} if (!"prop" in myObj) { // Noncompliant: checks whether !"prop", that is, false is in myObj doTheThing(); // this block is never executed } if (!foo instanceof MyClass) { // Noncompliant: "!foo" returns a boolean, which is not an instance of anything doTheOtherThing(); // this block is never executed either } ``` ```javascript Fix theme={null} if (!("prop" in myObj)) { doTheThing(); } if (!(foo instanceof MyClass)) { doTheOtherThing(); } ```

In React, a PureComponent is a class component that is optimized for performance by implementing a shallow comparison of props and state. It is a subclass of the regular React Component class and provides a default implementation of the shouldComponentUpdate method.

The shouldComponentUpdate method is responsible for determining whether a component should re-render or not. By default, it returns true and triggers a re-render every time the component receives new props or state. However, PureComponent overrides this method and performs a shallow comparison of the current and next props and state. If there are no changes, it prevents unnecessary re-renders by returning false.

Therefore, defining a shouldComponentUpdate method while extending PureComponent is redundant and should be avoided. By not defining shouldComponentUpdate, you allow React.PureComponent to handle the optimization for you.

```javascript Bad theme={null} class MyComponent extends React.PureComponent { // Noncompliant shouldComponentUpdate() { // does something } render() { return

Hello!

} } ``` ```javascript Fix theme={null} class MyComponent extends React.Component { shouldComponentUpdate() { // does something } render() { return

Hello!

} } ```

While most script engines support function declarations within blocks, from browser to browser, the implementations are inconsistent with each other.

```javascript Bad theme={null} if (x) { function foo() {} //foo is hoisted in Chrome, Firefox and Safari, but not in Edge. } ``` ```javascript Fix theme={null} if (x) { const foo = function() {} } ```

In TypeScript, optional and default parameters are features that enhance the flexibility and usability of functions by allowing you to define parameters that can be omitted during function calls or have default values assigned to them when not provided explicitly:

Optional parameters are denoted by adding a question mark (\`?) after the parameter name in the function declaration. These parameters can be omitted when calling the function, and TypeScript will assign them a value of undefined if they are not provided.
Default parameters are used to assign a default value to a parameter in case the caller does not provide a value for that parameter. Default values are specified in the function declaration using the assignment operator (=) followed by the default value.

When a parameter is defined as optional, it automatically allows that parameter to be omitted during function calls. If you explicitly pass undefined as the value for an optional parameter, it contradicts the purpose of making the parameter optional, making the code less readable and maintainable.

Similarly, when a parameter has a default value, it means that if the caller omits the argument during function calls, the default value will be used automatically. There is no need to pass undefined\` explicitly for default parameters, except when they come before a required parameter.

This rule checks that the last argument of a function call is not redundant with regard to the function’s signature.

```javascript Bad theme={null} function foo(x: number, y: string = "default", z?: number) { // ... } foo(42, undefined); // Noncompliant: 'undefined' is redundant foo(42, undefined, undefined); // Noncompliant: Both 'undefined' are redundant foo(42, undefined, 5); // Compliant: 'undefined' is required to get the second parameter's default value ``` ```javascript Fix theme={null} function foo(x: number, y: string = "default", z?: number) { // ... } foo(42); ```

Most checks against an indexOf value compare it with -1 because 0 is a valid index. Checking against > 0 ignores the first element, which is likely a bug.

```javascript Bad theme={null} let arr = ["blue", "red"]; if (arr.indexOf("blue") > 0) { // Noncompliant // ... } ``` ```javascript Fix theme={null} let arr = ["blue", "red"]; if (arr.includes("blue")) { // ... } ```

ts XSS vulnerabilities by automatically escaping HTML contents with the use of native API browsers like \`innerText instead of innerHtml.

It’s still possible to explicity use innerHtml\` and similar APIs to render HTML. Accidentally rendering malicious HTML data will introduce an XSS vulnerability in the application and enable a wide range of serious attacks like accessing/modifying sensitive information or impersonating other users.

```javascript Bad theme={null}

``` ```javascript Fix theme={null} Vue.component('element', { render: function (createElement) { return createElement( 'div', { domProps: { innerText: this.htmlContent, } }, this.htmlContent // Child node ); }, }); ```

jQuery doesn’t cache elements for you. If you’ve made a selection that you might need to make again, you should save the selection in a variable rather than making the selection repeatedly.

```javascript Bad theme={null} $( "p" ).hide(); $( "p" ).show(); // Noncompliant ``` ```javascript Fix theme={null} var paragraph = $( "p" ); paragraph.hide(); paragraph.show(); ```

React components should not be nested, as their state will be lost on each re-render of their parent component, possibly introducing bugs. This will also impact performance as child components will be recreated unnecessarily.

If the goal is to have the state reset, use a key instead of relying on a parent state.

```javascript Bad theme={null} function Component() { function NestedComponent() { // Noncompliant: NestedComponent should be moved outside Component return

; } return (

); } ``` ```javascript Fix theme={null} function Component() { return (

} /> { /* Noncompliant: Component is created inside prop */ }

); } ```

Bitwise operations are operations that manipulate individual bits in binary representations of numbers. These operations work at the binary level, treating numbers as sequences of 32 bits (in 32-bit environments) or 64 bits (in 64-bit environments). However, they should not be used in a boolean context because they have different behaviors compared to logical operators when applied to boolean values:

When applied to boolean values, bitwise AND (&) and OR (\`|) perform bitwise operations on the binary representation of the numbers. They treat the operands as 32-bit signed integers and manipulate their individual bits.
Logical AND (&&) and OR (||) are specifically designed for boolean operations. They return a boolean value based on the truthiness or falsiness of the operands.&& returns true if both operands are truthy; otherwise, it returns false. || operator returns true if at least one of the operands is truthy; otherwise, it returns false.

Bitwise operators & and | can be easily mistaken for logical operators && and ||, especially for those who are not familiar with the distinction between them or their specific use cases.

This rule raises an issue when & or |\` is used in a boolean context.

```javascript Bad theme={null} if (a & b) { /* ... */ } // Noncompliant: The operator & is used in a boolean context ``` ```javascript Fix theme={null} if (a && b) { /* ... */ } ```

The result of an expression with an arithmetic operator /, \*, %, ++, --, -, +=, -=, \*=, /=, %=, + or unary operator +, - when at least one operand is Object or Undefined will be always a NaN (Not a Number).

```javascript Bad theme={null} x = [1, 2]; var y = x / 4; //Noncompliant ``` ```javascript Fix theme={null} ```

In JavaScript, a setter is a special type of function that is used to set the value of a property on an object. Setters are defined using the \`set keyword followed by the name of the property that the setter is associated with.

To set the property, we simply assign a value to it as if it were a regular property. The setter function is automatically called with the value that we assign to the property.

Functions declared with the set\` keyword will automatically return the values they were passed. Thus any value explicitly returned from a setter will be ignored, and explicitly returning a value is a mistake.

```javascript Bad theme={null} let person = { // ... set firstname(first) { this.first = first; return 42; // Noncompliant: The return value 42 will be ignored } }; console.log(person.firstname = 'bob'); // Prints 'bob' ``` ```javascript Fix theme={null} let person = { // ... set firstname(first) { this.first = first; } }; console.log(person.firstname = 'bob'); // Prints 'bob' ```

In TypeScript, intersections are used to combine multiple types into a single one. An intersection type is represented using the ampersand symbol \`&. It allows you to combine multiple types into a single type that includes all the properties and methods from each type, thus creating more flexible and powerful type definitions.

However, some of the basic types of TypeScript should not be used with intersections:

The never type represents the type of values that never occur. Intersecting any type with never will always result in type never.
The any type allows to opt-out of type checking during compilation. Expressions of type any allow you to access arbitrary properties, even ones that don’t exist. any comes at the cost of losing type safety, which is one of the main motivations for using TypeScript. Avoid using any when not necessary. Intersecting any type with any will always result in type any.
The undefined and null types are the types for their respective value. Intersecting any type with them will always result in type never.
The void type implies the absence of a type. Intersecting any type with void will always result in type never.

Additionally, an intersection with a type without members (for example, \{}\`) doesn’t change the resulting type, is redundant, and can be safely removed from the intersection.

```javascript Bad theme={null} type Foo = T & null; // Noncompliant: 'Foo' is always 'never' type Bar = T & any; // Noncompliant: 'Bar' is always 'any' type Baz = T & U & {}; // Noncompliant: '{}' has no members and is redundant ``` ```javascript Fix theme={null} type Foo = T | null; type Bar = T & U; type Baz = T & U; ```

Referring to this in React functional components would be an error because the components are just regular JavaScript functions and do not have an object associated with them. Functional components receive their props as a first argument to the component function, so you can access them directly, and it is a common practice to destructure them right away.

```javascript Bad theme={null} function UserProfile({firstName, lastName}){ return (

{firstName} {lastName}

); } ``` ```javascript Fix theme={null} function MyComponent(props){ const foo = this.props.bar; // Noncompliant: remove 'this' return (

{foo}

); } ```

When a function is called, it executes its block of code and uses a \`return statement within the function to specify the value that the function will produce as its result. This returned value can then be used or assigned to a variable in the calling code.

If a function returns a value that is not used or assigned to a variable, it may indicate that the function is not being used correctly or that there is a mistake in the code. This can make the code harder to understand and maintain, and can also lead to errors if the return value is needed later in the code.

Ignoring the return value of a function can be a sign of poor coding practices. It can indicate that the developer did not fully understand the purpose of the function or did not take the time to properly integrate it into the code.

This rule triggers an issue only on a predefined list of methods from built-in objects (String, Number, Date, Array, Math, and RegExp\`) to prevent generating any false-positives.

```javascript Bad theme={null} 'hello'.lastIndexOf('e'); // Noncompliant: The return value is lost ``` ```javascript Fix theme={null} let lastIndex = 'hello'.lastIndexOf('e'); ```

In addition to being obtuse from a syntax perspective, function constructors are also dangerous: their execution evaluates the constructor’s string arguments similar to the way eval works, which could expose your program to random, unintended code which can be both slow and a security risk.

In general it is better to avoid it altogether, particularly when used to parse JSON data. You should use ECMAScript 5’s built-in JSON functions or a dedicated library.

```javascript Bad theme={null} var obj = new Function("return " + data)(); // Noncompliant ``` ```javascript Fix theme={null} var obj = JSON.parse(data); ```

The meaning of a boolean parameter may seem perfectly clear when you first write a method call, but that meaning is likely to fade for you over time, and could be completely opaque to those who come behind you.

Instead, object literals should be used.

```javascript Bad theme={null} widget.repaint(false); // Noncompliant; does this mean never repaint? ``` ```javascript Fix theme={null} widget.repaint({immediate: false}); ```

ECMAScript 2015 added the ability to use template literals instead of concatenation. Since their use is clearer and more concise, they are preferred in environments that support ECMAScript 2015.

```javascript Bad theme={null} function sayHello(name) { console.log("hello " + name); // Noncompliant } ``` ```javascript Fix theme={null} function sayHello(name) { console.log(`hello ${name}`); } ```

Shared coding conventions allow teams to collaborate efficiently. This rule checks that all members of a propTypes structure match a provided regular expression.

```javascript Bad theme={null} static propTypes = { enabled: React.PropTypes.bool.isRequired, // Noncompliant max_loops: React.PropTypes.number.isRequired, // Noncompliant FrameSrc: React.PropTypes.string.isRequired, // Noncompliant } ``` ```javascript Fix theme={null} static propTypes = { isEnabled: React.PropTypes.bool.isRequired, maxLoops: React.PropTypes.number.isRequired, frameSrc: React.PropTypes.string.isRequired, } ```

The Array.prototype.reduce() method in JavaScript is used to apply a function against an accumulator and each element in the array (from left to right) to reduce it to a single output value. It is a convenient method that can simplify logic in your code.

However, it’s important to always provide an initial value as the second argument to reduce(). The initial value is used as the first argument to the first call of the callback function. If no initial value is supplied, JavaScript will use the first element of the array as the initial accumulator value and start iterating at the second element.

This can lead to runtime errors if the array is empty, as reduce() will throw a TypeError.

```javascript Bad theme={null} function sum(xs) { return xs.reduce((acc, current) => acc + current); // Noncompliant } console.log(sum([1, 2, 3, 4, 5])); // Prints 15 console.log(sum([])); // TypeError: Reduce of empty array with no initial value ``` ```javascript Fix theme={null} function sum(xs) { return xs.reduce((acc, current) => acc + current, 0); } console.log(sum([1, 2, 3, 4, 5])); // Prints 15 console.log(sum([])); // Prints 0 ```

On the principle that clearer code is better code, you should explicitly import the things you want to use in a module. Using import \* imports everything in the module and risks confusing maintainers. Similarly, export \* from "module"; imports and then re-exports everything in the module and risks confusing not just maintainers but also the module’s users.

```javascript Bad theme={null} import * as Imported from "aModule"; // Noncompliant ``` ```javascript Fix theme={null} import {aType, aFunction} from "aModule"; ```

When you call a function in JavaScript and provide more arguments than the function expects, the extra arguments are simply ignored by the function.

```javascript Bad theme={null} function sum(a, b) { return a + b; } sum(1, 2, 3); // Noncompliant: The last argument is unexpected and will be ignored ``` ```javascript Fix theme={null} function sum() { let total = 0; for (let i = 0; i < arguments.length; i++) { total += arguments[i]; } return total; } sum(1, 2, 3); // Compliant ```

Every call to a function with a non-void return type is expected to return some value. If there is no value that’s valid, you should \`return undefined; rather than using a void return (return;). Conversely, every call to a function with a void return type is expected to not return any value, even undefined.

This rule raises an issue when undefined\` is returned from a void function, and when void is returned from a non-void function.

```javascript Bad theme={null} function nonvoidFunction(): number | undefined { return; // Noncompliant } function voidFunction(): void { return undefined; // Noncompliant } ``` ```javascript Fix theme={null} function nonvoidFunction(): number | undefined { return undefined; } function voidFunction(): void { return; } ```

In Chai.js, there is no inherent problem with giving the same argument twice in an assertion. It won’t cause any errors or issues in the test execution itself. The test will still run and pass as long as the assertion is correct.

However, having the same argument twice in an assertion might indicate a design issue or a potential mistake in your test. In most cases, you don’t need to compare a variable to itself in a test, as it doesn’t provide any meaningful validation and is likely to be a bug due to the developer’s carelessness.

This rule raises an issue when a Chai assertion is given twice the same argument.

```javascript Bad theme={null} const assert = require('chai').assert; describe("test the same object", function() { it("uses chai 'assert'", function() { const expected = '1'; const actual = (1).toString(); assert.equal(actual, actual); // Noncompliant: Asserting the same argument }); }); ``` ```javascript Fix theme={null} const assert = require('chai').assert; describe("test the same object", function() { it("uses chai 'assert'", function() { const expected = '1'; const actual = (1).toString(); assert.equal(actual, expected); }); }); ```

React has a special prop called dangerouslySetInnerHTML that allows you to assign a raw HTML string to the underlying DOM innerHTML property. Changing innerHTML will replace the element’s child nodes or text content. For this reason, dangerouslySetInnerHTML should never be used together with component children as they will conflict with each other, both trying to set the inner content of the same element.

```javascript Bad theme={null} function MyComponent() { return ( // Noncompliant: don't use children and dangerouslySetInnerHTML at the same time

Children

); } ``` ```javascript Fix theme={null} function MyComponent() { return (

); } ```

Call a non-callable symbol will result in a TypeError at execution.

```javascript Bad theme={null} function foo(a) { return a * 2; } // .... var foo = 1; // ... foo(); // foo is 1 => TypeError ``` ```javascript Fix theme={null} ```

An empty interface is equivalent to an empty object ('\{}'). Normally you cannot directly assign an object literal to a type when the object literal contains more properties than are specified in the type. But in the case of an empty interface, this check is not done, and such assignments will be successful. The result is highly likely to confuse maintainers.

```javascript Bad theme={null} interface A {} // Noncompliant ``` ```javascript Fix theme={null} interface A { foo: number; } ```

In JavaScript, the \`String.prototype.replace() method is used to replace parts of a string with new substrings. It allows you to perform simple to complex string replacements based on either a static string or a regular expression pattern.

When the first argument is a regular expression, the method will use the regular expression to search for matches within the original string and then replace those matches with the specified replacement. If the second argument is a string, the method will use it as the static replacement for the matched substrings found by the regular expression.

Within the replacement string, the function supports special placeholders to insert the matched values of capturing groups from the regular expression:

The \$n syntax allows you to reference capturing groups by their numerical index. The number n corresponds to the order in which the capturing group appears in the regular expression, starting from 1 for the first capturing group.
The \$\ syntax allows you to reference capturing groups by their name. Instead of using numerical indices, you can assign a name to a capturing group using ?\ within the regular expression.

If the second argument of String.prototype.replace() references non-existing groups (capturing groups that do not exist in the regular expression), the behavior of the replacement will depend on the specific references made. It won’t cause an error, but the replacement will not be based on any captured values, potentially leading to unexpected results in the replaced string:

If the replacement string contains references like $1, $2, etc., to capturing groups that don’t exist in the regular expression, those references will be treated as literals. In other words, the $n will be replaced with the literal text $n itself.
If the replacement string contains references like \$\, they will also be treated as literals, but only if there are no named captures in the regular expression; otherwise, they will be replaced with the empty string.

This rule checks that all referenced groups exist when replacing a pattern with a replacement string using String.prototype.replace() or String.prototype.replaceAll()\` methods.

```javascript Bad theme={null} const str = 'John Doe'; console.log(str.replace(/(\w+)\s(\w+)/, '$1, $0 $1')); // Noncompliant: index is 1-based, '$0' does not exist, prints 'John, $0 John' console.log(str.replace(/(?\w+)\s(?\w+)/, '$, $ $')); // Noncompliant: '$' does not exist but there are named captures, prints ', John ' ``` ```javascript Fix theme={null} const str = 'John Doe'; console.log(str.replace(/(\w+)\s(\w+)/, '$2, $1 $2')); console.log(str.replace(/(?\w+)\s(?\w+)/, '$, $ $')); ```

A for loop is a type of loop construct that allows a block of code to be executed repeatedly for a fixed number of times. The for loop is typically used when the number of iterations is known in advance, and consists of three parts:

The initialization statement is executed once at the beginning of the loop, and is used to initialize the loop counter or any other variables that may be used in the loop.
The loop condition is evaluated at the beginning of each iteration, and if it is true, the code inside the loop is executed.
The update statement is executed at the end of each iteration, and is used to update the loop counter or any other variables that may be used in the loop.

```javascript Bad theme={null} for (initialization; condition; update) { /*...*/ } ``` ```javascript Fix theme={null} for (;condition;) { /*...*/ } // Noncompliant: Only the condition is specified ```

JavaScript has the new keyword that is used in conjunction with constructor functions to create new instances of objects. When you use the new keyword with a function, it signifies that the function is intended to be used as a constructor function to create objects.

Any function can be used as a constructor function by convention. Constructor functions are used to create new objects with the same structure or properties. They are typically named with an initial capital letter to distinguish them from regular functions.

```javascript Bad theme={null} function Person(name, age) { this.name = name; this.age = age; } ``` ```javascript Fix theme={null} const person1 = new Person('Alice', 30); const person2 = new Person('Bob', 25); ```

In JavaScript, a generator is a special type of function that can be paused and resumed during its execution. It allows you to define an iterative algorithm by writing a function that can maintain its internal state and produce a sequence of values over time.

Generators are defined using a function syntax with an asterisk (*) appended to the function keyword (function*). Within the generator function, you can use the yield keyword to produce a value and temporarily pause the execution of the function, returning that value to the consumer.

```javascript Bad theme={null} function* generate() { yield 1; yield 2; yield 3; } ``` ```javascript Fix theme={null} function* range(start, end) { while (start < end) { yield; // Noncompliant: The generator yields undefined start++; } } ```

HTML5’s cross-window messaging adds the ability to send messages directly from one window (or iframe) to another, without having to go through a server. This makes it easier to write interesting and responsive web sites, but adds vulnerability as well, since the same-origin policy does not apply here. For that reason, cross-window messaging listeners should always check message origins and use only those from trusted sites.

This rule raises an issue on each cross-window messaging listener that does not check message origins.

```javascript Bad theme={null} window.addEventListener("message", function (event){ // Noncompliant // ... }, false); ``` ```javascript Fix theme={null} ```

HTML-style comments are not part of EcmaScript specification, and should not be used.

```javascript Bad theme={null} ``` ```javascript Fix theme={null} // Compliant /* Compliant */ ```

The \`delete operator can be used to remove a property from any object. Arrays are objects, so the delete operator can be used on them too.

When you delete an element from an array using the delete keyword, it will remove the value but still leave behind an empty slot at that index. Therefore, a hole will be created in the array because the indexes won’t be shifted to reflect the deletion. This means that the array will still have that index, but the value will be undefined\`.

Arrays that have gaps or missing indexes between elements are known as sparse arrays.

```javascript Bad theme={null} let myArray = ['a', 'b', 'c', 'd']; delete myArray[2]; // Noncompliant: myArray => ['a', 'b', undefined, 'd'] console.log(myArray[2]); // expected value was 'd' but output is undefined ``` ```javascript Fix theme={null} let myArray = ['a', 'b', 'c', 'd']; // removes 1 element from index 2 removed = myArray.splice(2, 1); // myArray => ['a', 'b', 'd'] console.log(myArray[2]); // outputs 'd' ```

The TypeScript programming language supports generics, a programming construct for creating reusable components, that is, components that can work over various types rather than a single one. Sometimes, we need to limit this genericity to a specific set of types, typically when we know these types share common capabilities, e.g., a length property. To this end, the language provides the extends clause to describe type constraints on type parameters, whether for classes, interfaces, type aliases, or functions.

By default, a type parameter extends the any type. It is therefore redundant to explicitly extend from any and should be removed accordingly.

```javascript Bad theme={null} class C { // ... } ``` ```javascript Fix theme={null} class C { // ... } ```

If you have an iterable, such as an array, set, or list, your best option for looping through its values is the for of syntax. Use for in and you’ll iterate the properties, rather than the values.

```javascript Bad theme={null} const arr = [4, 3, 2, 1]; for (let value in arr) { // Noncompliant console.log(value); // logs 0, 1, 2, 3 } ``` ```javascript Fix theme={null} const arr = [4, 3, 2, 1]; for (let value of arr) { console.log(value); } ```

In TypeScript, any is a type that is used when the type of a variable is unknown or could be of any type. It allows you to opt-out of type-checking and let the values pass through compile-time checks. In other words, it prevents the compiler from reporting type errors, which can lead to runtime errors.

On the other hand, unknown is a type-safe alternative to any. It forces you to perform certain checks before performing operations on variables of type unknown. This means you can’t accidentally perform arbitrary operations on variables of type unknown, which helps prevent runtime errors.

It’s generally recommended to avoid using any when possible, and instead use more specific types or generics for better type safety. If you want to maintain type safety, it’s better to use unknown instead of any.

```javascript Bad theme={null} function logValue(value: any) { // Noncompliant: 'value' is not type-checked console.log(value); } logValue(123); logValue('Hello'); ``` ```javascript Fix theme={null} function logValue(value: unknown) { if (typeof value === 'number') { console.log(value.toFixed(2)); } else if (typeof value === 'string') { console.log(value.trim()); } } logValue(123); logValue('Hello'); ```

In JavaScript, some \`Array methods do not mutate the existing array that the method was called on, but instead return a new array. Other methods mutate the array, and their return value differs depending on the method.

reverse and sort\` are mutating methods and, in addition, return the altered version. This rule raises an issue when the return values of these methods are assigned, which could lead maintainers to overlook the fact that the original array has been modified.

```javascript Bad theme={null} const reversed = a.reverse(); // Noncompliant: mutating method, no need to assign return value const sorted = b.sort(); // Noncompliant: mutating method, no need to assign return value ``` ```javascript Fix theme={null} a.reverse(); b.sort(); ```

When loading modules dynamically, malicious user input could find its way to the parameter specifying the module path and name. This could allow an attacker to load and run arbitrary code, or access arbitrary files.

This rule raises an issue for each use of dynamic module loading.

```javascript Bad theme={null} const mod = require(modPath); ``` ```javascript Fix theme={null} const mod = require('path/module'); ```

A unit test assertion should have only one reason to succeed because it helps to ensure that the test is focused and specific. When a test has multiple reasons to succeed, it becomes difficult to determine the root cause of a failure if the test fails. This can lead to confusion and wasted time trying to debug the test.

This rule raises an issue when the following Chai.js assertions are found:

When \`.not and .throw are used together and at least one argument is provided to .throw. Such assertions succeed when the target either does not throw any exception, or when it throws an exception different from the one provided.
When .not and .include are used together and an object is given to .include. Such assertions succeed when one or multiple key/values are missing.
When .not and .property are used together and .property is given at least two arguments. Such assertions succeed when the target either doesn’t have the requested property, or when this property exists but has a different value.
When .not and .ownPropertyDescriptor are used together and .ownPropertyDescriptor is given at least two arguments. Such assertions succeed when the target either doesn’t have the requested property descriptor, or its property descriptor is not deeply equal to the given descriptor
When .not and .members are used together. Such assertions succeed when one or multiple members are missing.
When .change and .by are used together. Such assertions succeed when the target either decreases or increases by the given delta
When .not and .increase are used together. Such assertions succeed when the target either decreases or stays the same.
When .not and .decrease are used together. Such assertions succeed when the target either increases or stays the same.
When .not negates .by. Such assertions succeed when the target didn’t change by one specific delta among all the possible deltas.
When .not and .finite are used together. Such assertions succeed when the target either is not a number, or is one of Nan, positive Infinity, negative Infinity\`.

```javascript Bad theme={null} const expect = require('chai').expect; describe("Each Chai.js assertion", function() { const throwsTypeError = () => { throw new TypeError() } it("has more than one reason to succeed", function() { expect(throwsTypeError).to.not.throw(ReferenceError) // Noncompliant expect({a: 42}).to.not.include({b: 10, c: 20}); // Noncompliant expect({a: 21}).to.not.have.property('b', 42); // Noncompliant expect({a: 21}).to.not.have.ownPropertyDescriptor('b', { // Noncompliant configurable: true, enumerable: true, writable: true, value: 42, }); expect([21, 42]).to.not.have.members([1, 2]); // Noncompliant let myObj = { value: 1 } const incThree = () => { myObj.value += 3; }; const decThree = () => { myObj.value -= 3; }; const doNothing = () => {}; expect(incThree).to.change(myObj, 'value').by(3); // Noncompliant expect(decThree).to.change(myObj, 'value').by(3); // Noncompliant expect(decThree).to.not.increase(myObj, 'value'); // Noncompliant expect(incThree).to.not.decrease(myObj, 'value'); // Noncompliant expect(doNothing).to.not.increase(myObj, 'value'); // Noncompliant expect(doNothing).to.not.decrease(myObj, 'value'); // Noncompliant expect(incThree).to.increase(myObj, 'value').but.not.by(1); // Noncompliant let toCheck; expect(toCheck).to.not.be.finite; // Noncompliant }); }); ``` ```javascript Fix theme={null} const expect = require('chai').expect; describe("Each Chai.js assertion", function() { const throwsTypeError = () => { throw new TypeError() } it("has only one reason to succeed", function() { expect(throwsTypeError).to.throw(TypeError) expect({a: 42}).to.not.have.any.keys('b', 'c'); expect({a: 21}).to.not.have.property('b'); expect({a: 21}).to.not.have.ownPropertyDescriptor('b'); expect([21, 42]).to.not.include(1).and.not.include(2); let myObj = { value: 1 } const incThree = () => { myObj.value += 3; }; const decThree = () => { myObj.value -= 3; }; const doNothing = () => {}; expect(incThree).to.increase(myObj, 'value').by(3); expect(decThree).to.decrease(myObj, 'value').by(3); expect(decThree).to.decrease(myObj, 'value').by(3); expect(incThree).to.increase(myObj, 'value').by(3); expect(doNothing).to.not.change(myObj, 'value'); expect(incThree).to.increase(myObj, 'value').by(3); let toCheck; // Either of the following is valid expect(toCheck).to.be.a('string'); expect(toCheck).to.be.NaN; expect(toCheck).to.equal(Infinity); expect(toCheck).to.equal(-Infinity); }); }); ```

The Web SQL Database standard never saw the light of day. It was first formulated, then deprecated by the W3C and was only implemented in some browsers. (It is not supported in Firefox or IE.)

Further, the use of a Web SQL Database poses security concerns, since you only need its name to access such a database.

```javascript Bad theme={null} var db = window.openDatabase("myDb", "1.0", "Personal secrets stored here", 2*1024*1024); // Noncompliant ``` ```javascript Fix theme={null} ```

JavaScript has the \`new keyword that is used in conjunction with constructor functions to create new instances of objects. When you use the new keyword with a function, it signifies that the function is intended to be used as a constructor function to create objects.

To create a new instance of an object using the constructor function, you use the new keyword before the function call.

The new keyword should only be used with objects that define a constructor function. Attempting to use it with an object or a variable that is not a constructor will raise a TypeError\`.

```javascript Bad theme={null} function MyClass() { this.foo = 'bar'; } const someClass = 1; const obj1 = new someClass; // Noncompliant: someClass is a variable const obj2 = new MyClass(); // Noncompliant if parameter considerJSDoc is true. Compliant when considerJSDoc is false ``` ```javascript Fix theme={null} /** * @constructor */ function MyClass() { this.foo = 'bar'; } const someClass = function(){ this.prop = 1; } const obj1 = new someClass; const obj2 = new MyClass(); ```

Numbers in JavaScript are stored in double-precision 64-bit binary format IEEE 754. Like any other number encoding occupying a finite number of bits, it is unable to represent all numbers.

The values are stored using 64 bits in the following form:

1 bit for the sign (positive or negative)
11 bits for the exponent (2ⁿ). -1022 ≤ n ≤ 1023
52 bits for the significand (or mantissa)

The actual value of the stored number will be (-1)^sign \* (1 + significand) \* 2 ^exponent

Given this structure, there are limits in both magnitude and precision.

Due to the 52 bits used for the significand, any arithmetic in need of more precision than 2^-52 (provided by Number.EPSILON) is subject to rounding.

In terms of magnitude, the largest number the 64 bits of the format can store is 2¹⁰²⁴ - 1 (Number.MAX\_VALUE).

However, because the 52 bits of the significand, only integers between -(2⁵³ - 1) (Number.MIN\_SAFE\_INTEGER) and 2⁵³ - 1 (Number.MAX\_SAFE\_INTEGER) can be represented exactly and be properly compared.

```javascript Bad theme={null} Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2; // true ``` ```javascript Fix theme={null} const myBigInt = BigInt(Number.MAX_SAFE_INTEGER); myBigInt + 1n === myBigInt + 2n; // false ```

In JavaScript, the \`in operator is primarily used to check if a property exists in an object or if an index exists in an array. However, it is not suitable for use with primitive types such as numbers, strings, or booleans because they are not objects and do not have properties.

If the right operand is of primitive type, the in operator raises a TypeError\`.

```javascript Bad theme={null} let x = "Foo"; "length" in x; // Noncompliant: TypeError 0 in x; // Noncompliant: TypeError "foobar" in x; // Noncompliant: TypeError ``` ```javascript Fix theme={null} let x = new String("Foo"); "length" in x; // true 0 in x; // true "foobar" in x; // false ```

In JavaScript, throwing literals (primitive values like strings, numbers, booleans, etc.) as exceptions is generally discouraged. While it is syntactically valid to throw literals, it is considered a best practice to throw instances of the \`Error class or its subclasses instead.

Throwing an instance of the Error class allows you to provide more meaningful information about the error.

The Error class and its subclasses provide properties like message and stack\` that can be used to convey useful details about the error, such as a description of the problem, the context in which it occurred, or a stack trace for debugging.

```javascript Bad theme={null} throw 404; // Noncompliant throw "Invalid negative index."; // Noncompliant ``` ```javascript Fix theme={null} throw new Error("Status: " + 404); throw new RangeError("Invalid negative index."); ```

Defining a object’s methods inside the object itself means that a new instance of the function is created for each instantiation of the object, bloating the instances.

Instead, it is more efficient to define the functions outside the object using the prototype keyword. This yields a single instance of each function, to which all the objects of that type refer.

```javascript Bad theme={null} function Person(firstName, middleInitial, lastName) { this.firstName = firstName; this.middleInitial = middleInitial; this.lastName = lastName; this.nameReversed = function() { // Noncompliant return this.lastName + ", " + this.firstName + " " + this.middleInitial; } } ``` ```javascript Fix theme={null} function Person(firstName, middleInitial, lastName) { this.firstName = firstName; this.middleInitial = middleInitial; this.lastName = lastName; } Person.prototype.nameReversed = function() { return this.lastName + ", " + this.firstName + " " + this.middleInitial; } ```

Object literal syntax, which initializes an object’s properties inside the object declaration is cleaner and clearer than the alternative: creating an empty object, and then giving it properties one by one.

An issue is raised when the following pattern is met:

An empty object is created.
A consecutive single-line statement adds a property to the created object.

```javascript Bad theme={null} let person = {}; // Noncompliant person.firstName = "John"; person.middleInitial = "Q"; person.lastName = "Public"; ``` ```javascript Fix theme={null} let person = { firstName: "John", middleInitial: "Q", lastName: "Public", } ```

Default parameter values allow callers to specify as many or as few arguments as they want while getting the same functionality and minimizing boilerplate, wrapper code, making a function easier to use.

All function parameters with default values should be declared after the function parameters without default values. Otherwise, it makes it impossible for callers to take advantage of defaults; they must re-specify the defaulted values or pass undefined to be able to specify the non-default parameters.

```javascript Bad theme={null} function multiply(a = 1, b) { // Noncompliant: parameter with default value should be last return a*b; } let x = multiply(1, 42); // Cannot benefit from default value ``` ```javascript Fix theme={null} function multiply(b, a = 1) { return a*b; } let x = multiply(42); ```

If a class method doesn’t access properties of that class (i.e. it doesn’t use this), it should be made static.

```javascript Bad theme={null} class Foo { constructor() { this.i = 1; } bar() { window.focus(); } } ``` ```javascript Fix theme={null} class Foo { constructor() { this.i = 1; } static bar() { window.focus(); } } ```

An async function always wraps the return value in a Promise. Using return await is not required and comes at an extra performance cost. However, you might wish to keep it as it preserves the function call in the stack trace in case an error is thrown asynchronously.

```javascript Bad theme={null} async function foo() { // ... } async function bar() { // ... return await foo(); // Noncompliant } ``` ```javascript Fix theme={null} async function foo() { // ... } async function bar() { // ... return foo(); } ```

If the class declaration does not include a constructor, one is automatically created, so there is no need to provide an empty constructor, or one that just delegates to the parent class.

```javascript Bad theme={null} class Foo { constructor() {} // Noncompliant, empty } class Bar extends Foo { constructor(params) { // Noncompliant: just delegates to the parent super(params); } } ``` ```javascript Fix theme={null} class Foo {} class Bar extends Foo {} ```

Initially, TypeScript defined "internal modules" and "external modules":

Internal modules: The module keyword was introduced in TypeScript to define internal modules. Internal modules were used to group classes, interfaces, and functions into logical units.
External modules refer to JavaScript modules, introduced in ECMAScript 2015. In TypeScript, just as in JavaScript (after ECMAScript 2015), any file containing a top-level import or export is considered a module.

However, in order to avoid confusion with similarly named terms, module was deprecated in favor of the namespace keyword, and "external modules" became simply "modules", as to align with ECMAScript 2015’s terminology.

Now that namespace is available, the use of module is deprecated because it does the same thing, and its use could confuse maintainers unaware of the history of the language. Therefore, the use of module is discouraged in TypeScript code.

```javascript Bad theme={null} module myMod { // Noncompliant // ... } ``` ```javascript Fix theme={null} namespace myMod { // ... } ```

If the function call can be written in a normal way, then calling that function with .call() or .apply() methods is redundant and can be removed without affecting the behavior of the code.

The .call() and .apply() methods are traditionally used to explicitely set the value of this keyword when executing a function or an object method. When calling a method of an object the value of this by default will be the reference to that object. But if you call a function or a method using .call() and .apply() you can set the value of this to any object, whatever you put into the first argument.

```javascript Bad theme={null} let obj = { checkThis() { this === obj; // true, if called the normal way: obj.checkThis() } }; let otherObject = {}; obj.checkThis.call(otherObject); // this === otherObject, if called this way ``` ```javascript Fix theme={null} foo.call(null, 1, 2); // Noncompliant: .call() is redundant obj.foo.call(obj, arg1, arg2); // Noncompliant: .call() is redundant bar.apply(undefined, [x, y, z]); // Noncompliant: .apply() is redundant ```

Deprecated methods are functions or properties that are no longer recommended and are likely to be removed in future updates of the library. They are often replaced with newer methods that offer better performance, security, or usability.

Using deprecated methods in React can lead to the following issues:

Code Maintainability: As deprecated methods are removed in future versions, the code will break if not updated. This can lead to increased time and effort in code maintenance.
Performance: Newer methods often come with performance improvements. Using deprecated methods can lead to slower app performance.
Security: Deprecated methods may have known security issues that are fixed in newer methods.

```javascript Bad theme={null} import React, { useState, useEffect } from 'react'; function MyComponent(props) { const [state, setState] = useState(initialState); componentWillReceiveProps(nextProps) { // Noncompliant: deprecated lifecycle method // Some code here... } componentWillUpdate(nextProps, nextState) { // Noncompliant: deprecated lifecycle method // Some code here... } render() { return

Hello World

; } } ``` ```javascript Fix theme={null} import React, { useState, useEffect } from 'react'; function MyComponent(props) { const [state, setState] = useState(initialState); // Using useEffect to replace deprecated lifecycle methods useEffect(() => { // Code to run on component update }, [props]); // This will run when `props` changes return

Hello World

; } ```

In JavaScript, a mutable variable is one whose value can be changed after it has been initially set. This is in contrast to immutable variables, whose values cannot be changed once they are set.

Exporting mutable variables can lead to unpredictable behavior and bugs in your code. This is because any module that imports the variable can change its value. If multiple modules import and change the value of the same variable, it can become difficult to track what the current value of the variable is and which module changed it last.

```javascript Bad theme={null} let mutableVar = "initial value"; export { mutableVar }; // Noncompliant ``` ```javascript Fix theme={null} const immutableVar = "constant value"; export { immutableVar }; ```

Using Function.prototype.bind and arrows functions as attributes will negatively impact performance in React. Each time the parent is rendered, the function will be re-created and trigger a render of the component causing excessive renders and more memory use. Wrapping the function in a useCallback hook will avoid additional renders. This rule ignores Refs. This rule does not raise findings on DOM nodes since that may require wrapping the DOM in a component. Still, better performance can be achieved if this rule is respected in DOM nodes too.

```javascript Bad theme={null} handleClick()}> ``` ```javascript Fix theme={null} function handleClick() { //... } ```

React isMounted() is primarily used to avoid calling setState() after a component has unmounted, because calling setState() after a component has unmounted will emit a warning. Checking isMounted() before calling setState() does eliminate the warning, but it also defeats the purpose of the warning, which is raising awareness that the app is still holding a reference to the component after the component has been unmounted.

When using ES6 classes, using isMounted() is already prohibited.

```javascript Bad theme={null} class MyComponent extends React.Component { componentDidMount() { mydatastore.subscribe(this); } dataHandler() { if (this.isMounted()) { // Noncompliant: isMounted() hides the error //... } } render() { //... calls dataHandler() } }; ``` ```javascript Fix theme={null} class MyComponent extends React.Component { componentDidMount() { mydatastore.subscribe(this); } dataHandler() { //... } render() { //... } componentWillUnmount() { mydatastore.unsubscribe(this); } } ```

Nested code blocks can be used to create a new scope: variables declared within that block cannot be accessed from the outside, and their lifetime end at the end of the block. However, this only happens when you use ES6 let or const keywords, a class declaration or a function declaration (in strict mode). Otherwise, the nested block is redundant and should be removed.

```javascript Bad theme={null} { let x = 1; } ``` ```javascript Fix theme={null} "use strict"; { function foo() {} } ```

In JavaScript, array indexes should be numeric because arrays are implemented as objects with numeric keys. When an array is created, it is actually an object with properties that are numeric keys. These keys are used to access and assign values stored in the array.

If an array index is not numeric, it will be converted to a string and used as a property name. This can lead to unexpected behavior, as properties are not guaranteed to be ordered in the same way as numeric indexes. For example, if an array has both numeric and non-numeric keys, the non-numeric keys may appear in a different order than the numeric keys.

```javascript Bad theme={null} let arr = []; arr[0] = 'a'; arr['name'] = 'bob'; // Noncompliant: The 'name' property with value 'bob' appears after the elements 'a' and 'foo' arr[1] = 'foo'; ``` ```javascript Fix theme={null} let arr = []; arr[0] = 'a'; arr[1] = 'foo'; arr[2] = 'bob'; ```

JavaScript and TypeScript classes may define a constructor method that is executed when a new instance is created. TypeScript allows interfaces that describe a static class object to define a new() method. Using these terms to name methods in other contexts can lead to confusion and make the code unclear and harder to understand.

This rule reports when:

A class defines a method named new. The new keyword is used to create new instances of the class. If a method with the same name is defined, it can be unclear whether the method is intended to create new instances or perform some other action.
An interface defines a method named constructor. The constructor method is used to define the constructor function for a class that implements the interface. If a method with the same name is defined in the interface, it can be unclear whether the method is intended to define the constructor function or perform some other action.

```javascript Bad theme={null} interface I { constructor(): void; // Noncompliant new(): I; } declare class C { constructor(); new(): C; // Noncompliant } ``` ```javascript Fix theme={null} interface I { new(): I; } declare class C { constructor(); } ```

The assignment of default parameter values is generally intended to help the caller. But when a default assignment causes side effects, the caller may not be aware of the extra changes or may not fully understand their implications. I.e. default assignments with side effects may end up hurting the caller, and for that reason, they should be avoided.

```javascript Bad theme={null} var count = 0; function go(i = count++) { // Noncompliant console.log(i); } go(); // outputs 0 go(7); // outputs 7 go(); // outputs 1 ``` ```javascript Fix theme={null} ```

The delete operator is used to remove a property from an object. It only affects its own properties. There are two valid ways to remove a property:

Using the dot notation: delete object.property
Using the bracket notation: delete object\[property]

delete will throw a TypeError in strict mode if the property is a non-configurable property.

delete identifier may work if identifier is a configurable property of the global object. For identifier to be configurable, it should have been declared directly as a globalThis property (globalThis.identifier = 1). This form is not common practice and should be avoided. Use delete globalThis.identifier instead if needed.

Aside from that case, deleting variables, including function parameters, never works:

Variables declared with var cannot be deleted from the global or a function’s scope, because while they may be attached to the global object, they are non-configurable. In CommonJS and ECMAScript modules, top-level variable declarations are scoped to the module and not attached to the global object.
Variables declared with let or const are not attached to any object.

```javascript Bad theme={null} var x = 1; delete x; // Noncompliant: depending on the context, this does nothing or throws TypeError function foo(){} delete foo; // Noncompliant: depending on the context, this does nothing or throws TypeError ``` ```javascript Fix theme={null} var obj = { x: 1, foo: function(){ ... } }; delete obj['x']; delete obj.foo; ```

When using the Backbone.js framework with model defaults that contain arrays or objects, defaults should be defined as a function rather than an object. This is because objects and arrays are passed by reference in JavaScript. So a defaults object that contains arrays or objects is going to set the default value of every instance to point to the same shared object or array.

Use a function instead and a fresh copy of the object or array will be peeled off for each instance.

```javascript Bad theme={null} var Person = Backbone.Model.extend({ defaults: { // Noncompliant; every instance of Person will share the same instance of favoriteColors favoriteColors: ["blue","purple","raspberry"] } }); ``` ```javascript Fix theme={null} var Person = Backbone.Model.extend({ defaults: function() { return { favoriteColors: ["blue","purple","raspberry"] }; } }); ```

Using an empty class serves no purpose and can hinder the readability of the code.

```javascript Bad theme={null} class Foo { static bar() { // ... } } ``` ```javascript Fix theme={null} export function bar() { // ... } ```

An iframe, or inline frame, is an HTML document embedded inside another HTML document on a website. The iframe HTML element is often used to insert content from another source, such as an advertisement, into a web page.

In the context of web accessibility, \'s should have a title</code> attribute. This is because screen readers for the visually impaired use this title to help users understand the content of the iframe.</p> </div> <div class="paragraph"> <p>Without a title, it can be difficult for these users to understand the context or purpose of the iframe’s content.</p> </div> <CodeGroup> ```javascript Bad theme={null} function iframe() { return ( <iframe src="https://openweathermap.org"> // Noncompliant ); } ``` ```javascript Fix theme={null} function iframe() { return ( ); } ```


      When a method return type is the declaring class name in a hierarchy of classes,
      it is impossible to chain methods defined in the superclass with methods defined in subclasses.



    
      ```javascript Bad theme={null}
      class RichText {
      constructor(private readonly text: string) {}
      bold(): RichText {
          // [...]
          return this;
      }
      italic(): RichText {
          // [...]
          return this;
      }
      }

      const richText = new RichText('Hello, World!');
      // Chaining methods bold() and italic().
      console.log(richText.bold().italic());
      ```

      ```javascript Fix theme={null}
      enum Color {
      RED, BLUE, GREEN
      }

      class Shape {
      // The return type is the class name.
      move(x: number, y: number): Shape {
          // [...]
          return this;
      }
      }

      class Polygon extends Shape {
      fill(color: Color): Polygon {
          // [...]
          return this;
      }
      }

      const polygon = new Polygon();
      polygon.move(1.0, 2.0).fill(Color.RED);
      //                     ^^^^
      //                     Property 'fill' does not exist on type 'Shape'.
      ```
    
  

  
    
      TypeScript provides two ways to tell the compiler that a literal value should be typed as a literal type like 42 rather than the primitive one number:
    

    
      
        
          as const tells TypeScript to infer the literal type automatically
        

        
          as T where T denotes a literal type to instruct TypeScript to infer the literal type explicitly
        
      
    

    
      In practice, as const is preferred because the type checker doesn’t need re-typing the literal value.
    

    
      Therefore, the rule flags occurrences of explicit literal types that can be replaced with an as const assertion.
    

    
      ```javascript Bad theme={null}
      class Foo {
      public static foo: 42 = 42; // Noncompliant

      // ...
      }
      ```

      ```javascript Fix theme={null}
      class Foo {
      public static foo = 42 as const;

      // ...
      }
      ```
    
  

  
    
      In JavaScript, there are two types of comparison operators: strict and non-strict.
    

    
      
        
          Strict operators: These operators compare both value and type. They are represented as === (strict equality) and !== (strict inequality). For example, \`5 =
        
      
    

    
      ```javascript Bad theme={null}
      function checkEqual(a, b) {
      if (a == b) { // Noncompliant: using non-strict equality '=='
      return "Equal";
      } else {
      return "Not equal";
      }
      }

      console.log(checkEqual(0, false)); // Output: "Equal"
      ```

      ```javascript Fix theme={null}
      function checkEqual(a, b) {
      if (a === b) {
      return "Equal";
      } else {
      return "Not equal";
      }
      }

      console.log(checkEqual(0, false)); // Output: "Not equal
      ```
    
  

  
    
      React does not always propagate component state changes to the underlying DOM elements immediately. If you modify the state during an already ongoing update cycle, the change may be delayed until the next update. React tries to keep this.state in sync with what is currently in the DOM, so you should never directly modify this.state yourself. Instead, use the asynchronous setState method instead, which allows React to properly manage the current state, trigger the new update cycle, or batch the updates together if necessary.
    

    
      Note that setState() is a request to change the state, not an immediate update. For example, if multiple components are changing the state in response to a user event, React will wait until the event handler has finished executing and then render all the changes in a single update. In other cases, the updates may be executed one at a time, so you should never make assumptions about how the component state will change in response to your request.
    

    
      If your next state is a function of the current state, you should pass an updater function to the setState() that will give you access to the correct component state at the time of the execution.
    

    
      The only place where you should directly modify the state is during the component initialization in a constructor function.
    

    
      ```javascript Bad theme={null}
      class MyComponent extends React.Component {
      constructor() {
      super();
      this.state = { 
        count: 0
      };
      }

      incrementCount() {
      this.state.count++; // Noncompliant: direct mutation of state object
      }

      render() {
      return (
        
          Count: {this.state.count}
          
        
      );
      }
      }
      ```

      ```javascript Fix theme={null}
      class MyComponent extends React.Component {
      constructor() {
      super();
      this.state = { 
        count: 0
      };
      }

      incrementCount() {
      this.setState(prevState => ({
        count: prevState.count + 1
      }));
      }

      render() {
      return (
        
          Count: {this.state.count}
          
        
      );
      }
      }
      ```
    
  

  
    
      Using the new operator with Symbol and BigInt will throw a TypeError because they are not intended to be used as constructors. Symbol and BigInt are primitive types in JavaScript and should be used as such.
    

    
      This is different from the other primitive types, such as string, number or boolean, where it was possible to call global String or Number as functions that return primitive types, but also use them as constructors with the new operator to create wrapper objects. This confusing double behavior is not implemented for Symbol and BigInt types that were introduced later in the language.
    

    
      This behavior would be especially problematic for symbols that have reference identity and already behave like objects in some way. For example, they are garbage collectable and therefore can be used as keys in WeakMap and WeakSet objects.
    

    
      ```javascript Bad theme={null}
      let foo = new Symbol('abc'); // Noncompliant: TypeError: Symbol is not a constructor
      let bar = new BigInt(123);   // Noncompliant: TypeError: BigInt is not a constructor
      ```

      ```javascript Fix theme={null}
      let foo = Symbol('abc');
      let bar = BigInt(123);
      ```
    
  

  
    
      While named function expressions might be useful for debugging purposes, some browsers do not support them correctly (for example Internet Explorer 8).
    

    

    
      ```javascript Bad theme={null}
      f = function fun(){}; // Noncompliant;  named function expression
      ```

      ```javascript Fix theme={null}
      fun = function(){}; // Compliant; function expression
      ```
    
  

  
    
      Screen readers require a specified language to function correctly. Without it, they default to the user’s set language, causing issues for multilingual users. Specifying a valid language ensures correct pronunciation and a less confusing experience.
    

    
      ```javascript Bad theme={null}
      
      ```

      ```javascript Fix theme={null}
      
      ```
    
  

  
    
      ARIA properties, also known as "aria-\* properties", are special attributes used in HTML to enhance the accessibility of web elements. They provide additional semantics to help assistive technologies, like screen readers, interpret the element.
    

    
      Roles, on the other hand, define what an element is or does in the context of a web page. Some elements have explicit roles, which are directly defined by the developer. For example, a div element might be given a role of "button". Other elements have implicit roles, which are inferred based on the type of the element. For example, an anchor tag \ has an implicit role of "link".

    


    
      This rule ensures that the ARIA properties used on an element are ones that are supported by the role of that element. For instance, the ARIA property aria-required is not supported by the role link. Therefore, using aria-required on an anchor tag would violate this rule.
    

    
      ```javascript Bad theme={null}
      Unchecked {/* Noncompliant: aria-chekd is not supported */}
      ```

      ```javascript Fix theme={null}
      Unchecked
      ```
    
  

  
    
      In JavaScript, every value can be coerced into a boolean value: either \`true or false. Values that are coerced into true are said to be truthy, and those coerced into false are said to be falsy.
    

    
      Explicit conversion to a boolean can be done with double negation (!!) or a Boolean\` call. Depending on the context, this may be redundant as JavaScript uses implicit type coercion and automatically converts values to booleans when used with logical operators, conditional statements, or any boolean context.
    

    
      ```javascript Bad theme={null}
      if (!!foo) { // Noncompliant: redundant '!!'
      // ...
      }

      if (Boolean(foo)) {  // Noncompliant: redundant 'Boolean' call
      // ...
      }
      ```

      ```javascript Fix theme={null}
      if (foo) {
      // ...
      }
      ```
    
  

  
    
      The ECMAScript specification allows for creating block-level lexical declarations (let, const, function, and class) in any block statement or expression. However, when these declarations are made inside the case or default clause of a switch statement, they are not confined to the block of that case or default clause. Instead, they apply to the whole switch block but only get initialized when the cases are reached, which can lead to unexpected behavior.
    

    
      ```javascript Bad theme={null}
      switch (foo) {
      case 1:
          let x = 1; // Noncompliant
          break;
      case 2:
          const y = 2; // Noncompliant
          break;
      case 3:
          function f() {} // Noncompliant
          break;
      case 4:
          class C {} // Noncompliant
          break;
      }
      ```

      ```javascript Fix theme={null}
      switch (foo) {
      case 1: {
          let x = 1;
          break;
      }
      case 2: {
          const y = 2;
          break;
      }
      case 3: {
          function f() {}
          break;
      }
      case 4: {
          class C {}
          break;
      }
      }
      ```
    
  

  
    
      Extra semicolons (\`;) are usually introduced by mistake, for example because:
    

    
      
        
          It was meant to be replaced by an actual statement, but this was forgotten.
        

        
          There was a typo which lead the semicolon to be doubled, i.e. ;;\`.
        

        
          There was a misunderstanding about where semicolons are required or useful.
        
      
    

    

    
      ```javascript Bad theme={null}
      var x = 1;; // Noncompliant

      function foo() {
      };  // Noncompliant
      ```

      ```javascript Fix theme={null}
      var x = 1;

      function foo() {
      }
      ```
    
  

  
    
      The fact that JavaScript is not a strongly typed language allows developers a lot of freedom, but that freedom can be dangerous if you go too far with it.
    

    
      Specifically, it is syntactically acceptable to invoke any expression as though its value were a function. But a TypeError may be raised if you do.
    

    

    
      ```javascript Bad theme={null}
      foo = 1;
      foo();   // Noncompliant; TypeError

      foo = undefined;
      foo();  // Noncompliant; TypeError
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      In JavaScript, a promise is an object representing the eventual completion or failure of an asynchronous operation. It is a way to handle asynchronous operations more elegantly and avoid the "callback hell".
    

    
      A promise can be in one of three states:
    

    
      
        
          Pending: The initial state of a promise. It represents that the asynchronous operation is still ongoing and has not yet been fulfilled or rejected.
        

        
          Fulfilled: The state of a promise when the asynchronous operation has been successfully completed. It represents that the promised value is available and can be consumed.
        

        
          Rejected: The state of a promise when the asynchronous operation encounters an error or fails to complete. It represents that an error has occurred and the promised value is not available.
        
      
    

    
      The basic syntax for creating a promise in JavaScript is as follows:
    

    
      ```javascript Bad theme={null}
      const myPromise = new Promise((resolve, reject) => {
      // Asynchronous operation
      // If the operation is successful, call resolve(value)
      // If the operation fails, call reject(error)
      });
      ```

      ```javascript Fix theme={null}
      const result = new Promise(resolve => resolve(42)); // Noncompliant: Redundant to explicitly create a promise to resolve 42
      result.then(value => {
      console.log(value); // Output: 42
      });
      ```
    
  

  
    
      When writing code, it is quite common to test patterns against string ends. For a long time, JavaScript did not provide proper support for this use case. As a result, developers have been relying on various programming subtleties to check the start or end of a string. Examples are getting the index of a substring, slicing the beginning of a string, extracting a substring from the head, matching a regular expression beginning or ending with a pattern, and so on.
    

    
      While these approaches are all technically valid, they look more like hacking than anything else, blur the developer’s intent, but more importantly affect code readability.
    

    
      Since ES2015, JavaScript provides String#startsWith and String#endsWith, which are the preferred ways to test patterns against string ends.
    

    
      ```javascript Bad theme={null}
      const str = 'abc';

      str[0] === 'a';
      str.charAt(0) === 'a';
      str.indexOf('abc') === 0;
      str.slice(0, 3) === 'abc';
      str.substring(0, 3) === 'abc';
      str.match(/^abc/) != null;
      /^abc/.test(str);
      ```

      ```javascript Fix theme={null}
      str.startsWith('abc');
      ```
    
  

  
    
      When a function in JavaScript does not have a return statement or if it has a return statement without a value, it implicitly returns undefined. This means that a function without a return statement or with an empty return statement is, in a way, a "void" function, as it doesn’t return any specific value.
    

    
      Therefore, attempting to use the return value of a void function in JavaScript is meaningless, and it can lead to unexpected behavior or errors.
    

    

    
      ```javascript Bad theme={null}
      function foo() {
      console.log("Hello, World!");
      }

      let a = foo(); // Noncompliant: Assigning the return value of a void function
      ```

      ```javascript Fix theme={null}
      function foo() {
      console.log("Hello, World!");
      }

      foo();
      ```
    
  

  
    
      React Legacy APIs provide a way to define the default values for props and check the prop types at runtime. This rule verifies if a defaultProps definition does have a corresponding propTypes definition. If it is missing, this could be the result of errors in refactoring or a spelling mistake.
    

    
      It is also an error if a defaultProp has propType that is marked as isRequired.
    

    
      ```javascript Bad theme={null}
      function MyComponent({foo, bar}) {
      return {foo}{bar};    
      }

      MyComponent.propTypes = {
      foo: React.PropTypes.string.isRequired,
      };

      MyComponent.defaultProps = {
      foo: "foo", // Noncompliant: foo is a required prop
      bar: "bar", // Noncompliant: bar propType is missing
      };
      ```

      ```javascript Fix theme={null}
      function MyComponent({foo, bar}) {
      return {foo}{bar};    
      }

      MyComponent.propTypes = {
      foo: React.PropTypes.string,
      bar: React.PropTypes.string,
      };

      MyComponent.defaultProps = {
      foo: "foo", 
      bar: "bar",
      };
      ```
    
  

  
    
      Logical AND (&&) operator is sometimes used to conditionally render in React (aka short-circuit evaluation). For example, myCondition && \ will return \ if myCondition is true and false otherwise.
    

    
      React considers false as a 'hole' in the JSX tree, just like null or undefined, and doesn’t render anything in its place. But if the condition has a falsy non-boolean value (e.g. 0), that value will leak into the rendered result.
    

    
      This rule will report when the condition has type number or bigint.
    

    
      In the case of React Native, the type string will also raise an error, as your render method will crash if you render 0, '', or NaN.
    

    
      ```javascript Bad theme={null}
      function Profile(props) {
      return 
      { props.username }
      { props.orders &&  } { /* Noncompliant: 0 will be rendered if no orders available */ }
      ;
      }
      ```

      ```javascript Fix theme={null}
      function Profile(props) {
      return 
      { props.username }
      { props.orders > 0 &&  }
      ;
      }
      ```
    
  

  
    
      ARIA (Accessible Rich Internet Applications) roles are used to make web content and web applications more accessible to people with disabilities. However, you should not use an ARIA role on a generic element (like span or div) if there is a semantic HTML tag with similar functionality, just use that tag instead.
    

    
      For example, instead of using a div element with a button role (\
Click me\
), you should just use a button element (\).
    

    
      Semantic HTML tags are generally preferred over ARIA roles for accessibility due to their built-in functionality, universal support by browsers and assistive technologies, simplicity, and maintainability. They come with inherent behaviors and keyboard interactions, reducing the need for additional JavaScript. Semantic HTML also enhances SEO by helping search engines better understand the content and structure of web pages. While ARIA roles are useful, they should be considered a last resort when no suitable HTML element can provide the required behavior or semantics.
    

    
      ```javascript Bad theme={null}
      Click me
      ```

      ```javascript Fix theme={null}
      
      ```
    
  

  
    
      React Refs provide a way to access DOM nodes or React elements created in the render method.
    

    
      Older React versions allowed the ref attribute to be a string, like "textInput", later accessible as this.refs.textInput. This is considered legacy code due to multiple reasons:
    

    
      
        
          String refs make React slower as they force React to keep track of what component is currently executing.
        

        
          String refs are not composable: if a library puts a ref on the passed child, the user can’t put another ref on it.
        

        
          The owner of a string ref is determined by the currently executing component.
        
      
    

    
      ```javascript Bad theme={null}
      const Hello = createReactClass({
      componentDidMount() {
      const component = this.refs.hello; // Noncompliant
      // ...
      },
      render() {
      return Hello, world.;
      }
      });
      ```

      ```javascript Fix theme={null}
      const Hello = createReactClass({
      componentDidMount() {
      const component = this.hello;
      // ...
      },
      render() {
      return  { this.hello = c; }}>Hello, world.;
      }
      });
      ```
    
  

  
    
      The parseInt function has two versions, one that takes a base value as a second argument, and one that does not. Unfortunately using the single-arg version can result in unexpected results on older browsers.
    

    

    
      ```javascript Bad theme={null}
      parseInt("010");  // Noncompliant; pre-2013 browsers may return 8
      ```

      ```javascript Fix theme={null}
      parseInt("010", 10);
      ```
    
  

  
    
      JSX lets you write HTML-like markup inside a JavaScript file, commonly used in React.
    

    
      Adding comments inside JSX might be tricky as JSX code is neither a plain HTML nor JavaScript.
    

    
      HTML comments (\) are not valid syntax in JSX.
    

    
      JavaScript-style comments, single or multiline, will create an additional text node in the browser, which is probably not expected.
    

    
      ```javascript Bad theme={null}
      
      // Noncompliant: text inside node
      
      ```

      ```javascript Fix theme={null}
      
      {
      /*
        multi-line
        comment
      */
      }
      {
      // single-line comment
      }
      { /* short form comment */ }
      
      ```
    
  

  
    
      Offering the same experience with the mouse and the keyboard allow users to pick their preferred devices.
    

    
      Additionally, users of assistive technology will also be able to browse the site even if they cannot use the mouse.
    

    
      This rules detects the following issues:
    

    
      
        
          when onClick is not accompanied by at least one of the following: onKeyUp, onKeyDown, onKeyPress.
        

        
          when onmouseover/onmouseout are not paired by onfocus/onblur.
        
      
    

    
      ```javascript Bad theme={null}
       {}} />

       {}} }  />
      ```

      ```javascript Fix theme={null}
       {}} onKeyDown={this.handleKeyDown} />

       {} } onFocus={ () => {} } />
      ```
    
  

  
    
      Consistent naming between arguments and parameters reduces the chances of making mistakes, such as passing the wrong value to a parameter or omitting an argument in a function call. When the names of arguments in a function call match the names of the function parameters, it contributes to clearer, more readable code.
    

    
      However, when the names match but are passed in a different order than their declaration in the function signature, it may indicate a mistake in the parameter order, likely leading to unexpected results.
    

    
      ```javascript Bad theme={null}
      function divide(dividend, divisor) {
      return dividend / divisor;
      }

      function doTheThing() {
      const dividend = 15;
      const divisor = 5;

      const result = divide(divisor, dividend); // Noncompliant: not the expected result
      //...
      }
      ```

      ```javascript Fix theme={null}
      function divide(dividend, divisor) {
      return dividend / divisor;
      }

      function doTheThing() {
      const dividend = 15;
      const divisor = 5;

      const result = divide(dividend, divisor);
      //...
      }
      ```
    
  

  
    
      Leaving unused props in a React component can make the code harder to understand and maintain. Other developers may wonder why certain props are passed to a component if they are not used. Unused props can also increase the size of the component’s memory footprint and impact performance. This is especially true if the unused props are large objects or arrays. Furthermore, if a prop is unused, it may indicate that the developer did not complete the implementation as he intended initially or made a mistake while writing the component.
    

    
      To avoid these issues, you should remove any unused props from React components. This helps keep the codebase clean, improves performance, and enhances code readability.
    

    
      ```javascript Bad theme={null}
      import PropTypes from 'prop-types';
      import React from 'react';

      class Hello extends React.Component {
      render() {
      return (
        Hello
      );
      }
      }

      Hello.propTypes = {
      name: PropTypes.string
      };
      ```

      ```javascript Fix theme={null}
      import PropTypes from 'prop-types';
      import React from 'react';

      class Hello extends React.Component {
      render() {
      return (
        Hello {this.props.name}
      );
      }
      }

      Hello.propTypes = {
      name: PropTypes.string
      };
      ```
    
  

  
    
      Template literals, also known as template strings, allow for string interpolation and multiline strings in JavaScript. They provide a more convenient and flexible way to work with strings compared to traditional string concatenation or manipulation.
    

    
      Template literals are delimited with the backtick () character. They are a convenient way to include variables or expressions within a string using placeholders \$\{expression}\` in the string and evaluate them dynamically.
    

    
      However, nesting template literals can make the code less readable. With each nested template literal, the code becomes more complex and harder to understand. It can be challenging to keep track of the opening and closing backticks and properly escape characters if needed.
    

    
      ```javascript Bad theme={null}
      const color = "red";
      const count = 3;
      const message = `I have ${color ? `${count} ${color}` : count} apples`; // Noncompliant: nested template strings not easy to read
      ```

      ```javascript Fix theme={null}
      const color = "red";
      const count = 3;
      const apples = color ? `${count} ${color}` : count;
      const message = `I have ${apples} apples`;
      ```
    
  

  
    
      Unnecessary imports refer to importing modules, libraries, or dependencies that are not used or referenced anywhere in the code. These imports do not contribute to the functionality of the application and only add extra weight to the JavaScript bundle, leading to potential performance and maintainability issues.
    

    
      ```javascript Bad theme={null}
      import A from 'a'; // Noncompliant: The imported symbol 'A' isn't used
      import { B1 } from 'b';

      console.log(B1);
      ```

      ```javascript Fix theme={null}
      import { B1 } from 'b';

      console.log(B1);
      ```
    
  

  
    
      The \`for...in statement allows you to loop through the names of all of the properties of an object. The list of properties includes all those properties that were inherited through the prototype chain. This has the side effect of serving up functions when the interest is in data properties. Programs that don’t take this into account can fail.
    

    
      Therefore, the body of every for...in statement should be wrapped in an if\` statement that filters which properties are acted upon. It can select for a particular type or range of values, or it can exclude functions, or it can exclude properties from the prototype.
    

    

    
      ```javascript Bad theme={null}
      for (name in object) {
      doSomething(name);  // Noncompliant
      }
      ```

      ```javascript Fix theme={null}
      for (name in object) {
      if (object.hasOwnProperty(name)) {
      doSomething(name);
      }
      }
      ```
    
  

  
    
      Using element type in class selectors is slower than using only the class selector.
    

    

    
      ```javascript Bad theme={null}
      var $products = $("div.products");    // Noncompliant - slow
      ```

      ```javascript Fix theme={null}
      var $products = $(".products");    // Compliant - fast
      ```
    
  

  
    
      Instead of creating an array and then setting its items one by one, creation an initialization can - and should - happen all in one step. Doing so results in clearer code and eliminates the possibility that an item might be accidentally overwritten or left uninitialized.
    

    

    
      ```javascript Bad theme={null}
      var colors = [];  // Noncompliant
      colors[1] = "red";  // Oops! Explicit initialization means that the 0th element is left empty
      colors[2] = "green";
      colors[2] = "blue"; // Oops again! "green" overwritten
      ```

      ```javascript Fix theme={null}
      var colors = ["red","green","blue"];
      ```
    
  

  
    
      The \`if...else statement is used to make decisions based on the truthiness of a boolean expression, and the if block executes when the expression is truthy, while the else block executes when the expression is falsy.
    

    
      Wrapping a boolean expression in an if...else statement and returning true or false\` in the respective blocks is redundant and unnecessary. It can also make the code harder to maintain, as it adds unnecessary lines of code that need to be read and understood.
    

    
      ```javascript Bad theme={null}
      if (expression) {  
      return true;
      } else {
      return false;
      }
      ```

      ```javascript Fix theme={null}
      return expression;
      ```
    
  

  
    
      Array literals should always be preferred to Array constructors.
    

    
      Array constructors are error-prone due to the way their arguments are interpreted. If more than one argument is used, the array length will be equal to the number of arguments. However, using a single argument will have one of three consequences:
    

    
      
        
          If the argument is a number and it is a natural number the length will be equal to the value of the argument.
        
      
    

    
      
        let arr = new Array(3); // \[empty × 3]
      
    

    
      
        
          If the argument is a number, but not a natural number an exception will be thrown.
        
      
    

    
      
        let arr = new Array(3.14);  // RangeError: Invalid array length
      
    

    
      
        
          Otherwise the array will have one element with the argument as its value.
        
      
    

    
      
        let arr = new Array("3");  // \["3"]
      
    

    
      Note that even if you set the length of an array, it will be empty. That is, it will have the number of elements you declared, but they won’t contain anything, so no callbacks will be applied to the array elements.
    

    
      For these reasons, if someone changes the code to pass 1 argument instead of 2 arguments, the array might not have the expected length. To avoid these kinds of weird cases, always use the more readable array literal initialization format.
    

    

    
      ```javascript Bad theme={null}
      let myArray = new Array(x1, x2, x3);   // Noncompliant. Results in 3-element array.
      let emptyArray = new Array();          // Noncompliant. Results in 0-element array.

      let unstableArray = new Array(n);      // Noncompliant. Variable in results.

      let arr = new Array(3); // Noncompliant; empty array of length 3
      arr.foreach((x) => alert("Hello " + x)); // callback is not executed because there's nothing in arr
      let anotherArr = arr.map(() => 42); // anotherArr is also empty because callback didn't execute
      ```

      ```javascript Fix theme={null}
      let myArray = [x1, x2, x3];
      let emptyArray = [];

      // if "n" is the only array element 
      let unstableArray = [n];
      // or,  if "n" is the array length (since ES 2015)
      let unstableArray = Array.from({length: n});

      let arr = ["Elena", "Mike", "Sarah"];
      arr.foreach((x) => alert("Hello " + x));
      let anotherArr = arr.map(() => 42);  // anotherArr now holds 42 in each element
      ```
    
  

  
    
      The optional chaining operator ?. allows to access a deeply nested property, returning undefined if the property or any intermediate object is undefined.
    

    
      This usually means that the expression is expected to evaluate as undefined in some cases. Therefore, using the optional chaining operator in a context where returning undefined throws an error can lead to runtime exceptions.
    

    
      ```javascript Bad theme={null}
      (event?.callback)(); // Noncompliant: when 'event' does not have 'callback' property TypeError is thrown
      const { code } = event?.error; // Noncompliant: when 'event' does not have 'error' property TypeError is thrown
      func(...event?.values); // Noncompliant: when 'event' does not have 'values' property TypeError is thrown
      ```

      ```javascript Fix theme={null}
      (event?.callback ?? defaultCallback)();
      ```
    
  

  
    
      undefined is the value you get for variables and properties which have not yet been created. Use the same value to reset an existing variable and you lose the ability to distinguish between a variable that exists but has no value and a variable that does not yet exist. Instead, null should be used, allowing you to tell the difference between a property that has been reset and one that was never created.
    

    

    
      ```javascript Bad theme={null}
      var myObject = {};

      // ...
      myObject.fname = undefined;  // Noncompliant
      // ...

      if (myObject.lname == undefined) {
      // property not yet created
      }
      if (myObject.fname == undefined) {
      // no real way of knowing the true state of myObject.fname
      }
      ```

      ```javascript Fix theme={null}
      var myObject = {};

      // ...
      myObject.fname = null;
      // ...

      if (myObject.lname == undefined) {
      // property not yet created
      }
      if (myObject.fname == undefined) {
      // no real way of knowing the true state of myObject.fname
      }
      ```
    
  

  
    
      Shared coding conventions allow teams to collaborate effectively. This rule checks that classes extending React.PureComponent or React.Component are named with UpperCamelCase (aka PascalCase).
    

    

    
      ```javascript Bad theme={null}
      export default class my-super-component extends React.PureComponent { // Noncompliant
      ...
      }
      ```

      ```javascript Fix theme={null}
      export default class MySuperComponent extends React.PureComponent {
      ...
      }
      ```
    
  

  
    
      To optimize the rendering of React list components, a unique identifier (UID) is required for each list item. This UID lets React identify the item throughout its lifetime. To provide it, use the key attribute of the list item. When the key attribute is missing, React will default to using the item’s index inside the list component. If the element ordering changes, it will cause keys to not match up between renders, recreating the DOM. It can negatively impact performance and may cause issues with the component state.
    

    
      ```javascript Bad theme={null}
      function Blog(props) {
      return (
      
        {props.posts.map((post) =>
           
            {post.title}
          
        )}
      
      );
      }
      ```

      ```javascript Fix theme={null}
      function Blog(props) {
      return (
      
        {props.posts.map((post) =>
           
            {post.title}
          
        )}
      
      );
      }
      ```
    
  

  
    
      A loop is a control structure that allows a block of code to be executed repeatedly until a certain condition is met. The basic idea behind a loop is to automate repetitive tasks, such as iterating over a collection of data or performing a calculation multiple times with different inputs.
    

    
      An infinite loop is a loop that runs indefinitely without ever terminating. In other words, the loop condition is always true, and the loop never exits. This can happen when the loop condition is not defined or when the loop condition is never met.
    

    
      Infinite loops can cause a program to hang or crash, as the program will continue to execute the loop indefinitely.
    

    
      This rule will raise an issue on for, while and do...while loops where no clear exit condition has been found.
    

    
      There are some known limitations for this rule:
    

    
      
        
          False positives: when an exception is raised by a function invoked within the loop.
        

        
          False negatives: when a loop condition is based on an element of an array or object.
        
      
    

    
      ```javascript Bad theme={null}
      for (;;) {  // Noncompliant: end condition omitted
      // ...
      }

      let j = 0;
      while (true) { // Noncompliant: constant end condition
      j++;
      }

      let k;
      let b = true;
      while (b) { // Noncompliant: constant end condition
      k++;
      }
      ```

      ```javascript Fix theme={null}
      for (let i = 0; i < 5; i++) {
      // ...
      }

      let j = 0;
      while (true) {
      j++;
      if (j < 5) {
      break;
      }
      }

      let k;
      let b = true;
      while (b) {
      k++;
      b = k < 10;
      }
      ```
    
  

  
    
      React fragments are a feature in React that allows you to group multiple elements together without adding an extra DOM element. They are a way to return multiple elements from a component’s render method without requiring a wrapping parent element.
    

    
      However, a fragment is redundant if it contains only one child, or if it is the child of an HTML element.
    

    
      ```javascript Bad theme={null}
      <>;    // Noncompliant: The fragment has only one child
      <>foo; // Noncompliant: The fragment is the child of the HTML element 'p'
      ```

      ```javascript Fix theme={null}
      ;
      foo;
      ```
    
  

  
    
      The JavaScript wrapper objects Number, String, and Boolean provide a way to work with their respective primitive types (number, string and boolean) as objects.
    

    
      Using wrapper can lead to unexpected behavior due to the differences in how they are compared and used in operations compared to primitive types. It can also lead to unnecessary memory allocation and slower code execution.
    

    
      ```javascript Bad theme={null}
      let x = new Number("0"); // Noncompliant: x is an object, not a primitive
      if (x) {
      alert('hi');  // Shows 'hi'.
      }
      ```

      ```javascript Fix theme={null}
      let x = Number("0");
      if (x) {
      alert('hi');
      }
      ```
    
  

  
    
      Captions in HTML media elements are text versions of the audio content, synchronized with the video. They are essential for individuals who are deaf or hard of hearing, as they provide a text alternative for the audio information. They can also be beneficial for individuals who are not native speakers of the language of the video, or for situations where the audio cannot be heard.
    

    
      In the context of accessibility, providing captions for media elements is a requirement under the Web Content Accessibility Guidelines (WCAG). Without captions, you are excluding a portion of your audience who rely on them to understand the content of your media.
    

    
      ```javascript Bad theme={null}
      
  

  
    
      Shared coding conventions allow teams to collaborate effectively. This rule raises an issue when the use of spaces within a template does not conform to the configured style.
    

    

    
      ```javascript Bad theme={null}
      `Hello, ${world }!`; // Noncompliant
      ```

      ```javascript Fix theme={null}
      `Hello, ${world}!`;
      ```
    
  

  
    
      When a non-existent variable is referenced a \`ReferenceError is raised.
    

    
      Due to the dynamic nature of JavaScript this can happen in a number of scenarios:
    

    
      
        
          When typo was made in a symbol’s name.
        

        
          When using variable declared with let or const before declaration (unlike var-declarations, they are not hoisted to the top of the scope).
        

        
          Due to confusion with scopes of let- and const-declarations (they have block scope, unlike var-declarations, having function scope).
        

        
          When accessing a property in the wrong scope (e.g. forgetting to specify this.).
        
      
    

    
      This rule does not raise issues on global variables which are defined with sonar.javascript.globals and sonar.javascript.environments\` properties.
    

    

    
      ```javascript Bad theme={null}
      var john = { 
      firstName: "john", 
      show: function() { console.log(firstName); } // Noncompliant: firstName is not defined
      }
      john.show();
      ```

      ```javascript Fix theme={null}
      var john = { 
      firstName: "john", 
      show: function() { console.log(this.firstName); }
      }
      john.show();
      ```
    
  

  
    
      In JavaScript, null and undefined are primitive values that do not have properties or methods. When accessing a property on a null or undefined value, JavaScript tries to access the property of an object that does not exist, which results in a TypeError.
    

    
      This can cause the program to crash or behave unexpectedly, which can be difficult to debug.
    

    
      ```javascript Bad theme={null}
      let foo = null;
      console.log(foo.bar); // Noncompliant: TypeError will be thrown
      ```

      ```javascript Fix theme={null}
      let foo;
      if (foo != null) {
      console.log(foo.bar);
      }
      ```
    
  

  
    
      A type guard is a TypeScript feature that allows you to narrow the type of a variable within a conditional block of code. It is a way to tell the TypeScript compiler that an expression is of a certain type, based on some condition that you check at runtime.
    

    
      ```javascript Bad theme={null}
      function printLength(x: any) {
      if (typeof x === 'string') {
      console.log(x.length);
      }
      }
      ```

      ```javascript Fix theme={null}
      function isString(x: any): x is string {
      return typeof x === 'string';
      }

      function printLength(x: any) {
      if (isString(x)) {
      console.log(x.length);
      }
      }
      ```
    
  

  
    
      To optimize the rendering of React list components, a unique identifier (UID) is required for each list item. This UID lets React identify the item throughout its lifetime. Avoid array indexes since the order of the items may change, which will cause keys to not match up between renders, recreating the DOM. It can negatively impact performance and may cause issues with the component state.
    

    
      ```javascript Bad theme={null}
      function Blog(props) {
      return (
      
        {props.posts.map((post, index) =>
           
            {post.title}
          
        )}
      
      );
      }
      ```

      ```javascript Fix theme={null}
      function Blog(props) {
      return (
      
        {props.posts.map((post) =>
          
            {post.title}
          
        )}
      
      );
      }
      ```
    
  

  
    
      By default, JavaScript allows you to modify native object prototypes, such as Array, String, Object, and so on. This means you can add new properties or methods to native objects or override existing ones. While this flexibility can be useful in some instances, it can lead to unexpected behavior, bugs, and compatibility issues.
    

    
      The rule forbids extending or modifying native JavaScript objects or prototypes, as prototypes of builtin objects should not be modified altogether.
    

    
      ```javascript Bad theme={null}
      Object.prototype.universe = 42;
      Object.defineProperty(Array.prototype, "size", { value: 0 });
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      Reading a non-existent property on an object always returns \`undefined. Doing so is usually an error; either in the name of the property or the type of the variable being accessed.
    

    
      If an attempt is made to access properties of a primitive, the primitive is automatically encased in a primitive-wrapper object for the operation. But being "promoted" to an object doesn’t mean that the primitive will actually have properties to access. The wrapper object still won’t have the non-existent property and undefined will be returned instead.
    

    
      This rule raises an issue when an attempt is made to access properties of a primitive. Thus this rule should only be activated when you don’t use monkey patching for standard objects, like Number, Boolean and String\`.
    

    

    
      ```javascript Bad theme={null}
      x = 42;
      y = x.length;   // Noncompliant, Number type doesn't have "length" property
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      An expression that always produces the same result, regardless of the inputs, is unnecessary and likely indicates a programmer’s error. This can come from
    

    
      
        
          confusing operator precedence
        

        
          expecting strict equality between different types
        

        
          expecting objects to be compared by value
        

        
          expecting empty objects to be false or null
        

        
          mistyping >= for ⇒
        
      
    

    
      This can also happen when you put an assignment in a logical sub-expression. While not strictly a bug, this practice is confusing and should be avoided.
    

    
      ```javascript Bad theme={null}
      !foo == null;
      a + b ?? c; 
      x === [];
      (foo=0) && bar;
      ```

      ```javascript Fix theme={null}
      foo != null;
      a + (b ?? c);
      x.length === 0;
      ```
    
  

  
    
      String.match() behaves the same way as RegExp.exec() when the regular expression does not include the global flag g. While they work the same, RegExp.exec() can be slightly faster than String.match(). Therefore, it should be preferred for better performance.
    

    
      The rule reports an issue on a call to String.match() whenever it can be replaced with semantically equivalent RegExp.exec().
    

    
      ```javascript Bad theme={null}
      'foo'.match(/bar/);
      ```

      ```javascript Fix theme={null}
      /bar/.exec('foo');
      ```
    
  

  
    
      The use of the comma operator and logical OR (||) operator within switch cases is not recommended. The switch statement is designed to evaluate a single expression and compare it against multiple values. When you use the comma operator or logical OR operator within a case, you’re essentially trying to match multiple values or conditions simultaneously: only the rightmost value will ever be considered with the comma operator, and the first truthy operand will be handled with the logical OR operator.
    

    
      This behavior is not well-defined and can lead to unexpected results.
    

    
      ```javascript Bad theme={null}
      switch (a) {
      case 1, 2:   // Noncompliant: only 2 is matched by this case
      doTheThing(a);
      case 3 || 4: // Noncompliant: only 3 is matched by this case
      doThatThing(a);
      case 5:
      doTheOtherThing(a);
      default:
      console.log('Neener, neener!');
      }
      ```

      ```javascript Fix theme={null}
      switch (a) {
      case 1:
      case 2:
      doTheThing(a);
      case 3:
      case 4:
      doThatThing(a);
      case 5:
      doTheOtherThing(a);
      default:
      console.log('Neener, neener!');
      }
      ```
    
  

  
    
      Promises need to be resolved or awaited to return the expected value, otherwise, they return the promise object.
    

    
      Unresolved promises:
    

    
      Forgetting to await a promise is a frequent mistake. There are places where the use of a promise object is confusing or unclear because the developer forgot to resolve it.
    

    
      This rule forbids returning promises where another type is expected such as in:
    

    
      
        
          conditionals
        

        
          void returns
        

        
          spread operators
        
      
    

    

    
      ```javascript Bad theme={null}
      await new Promise(resolve => time.setTimeout(1000));
      ```

      ```javascript Fix theme={null}
      (async function foo() {
      const result = await bar();
      // work with result
      })();
      ```
    
  

  
    
      In JavaScript, many array methods take a callback function as an argument. These methods are designed to transform or filter arrays based on the logic provided in the callback function. The callback function is called sequentially, and the return value of the callback function is used to determine the return value of the Array method.
    

    
      If the callback function does not return a value, the array method may not work as expected and is most likely a mistake.
    

    
      This rule applies to the following methods of an array:
    

    
      
        
          \`Array.from
        

        
          Array.prototype.every
        

        
          Array.prototype.filter
        

        
          Array.prototype.find
        

        
          Array.prototype.findLast
        

        
          Array.prototype.findIndex
        

        
          Array.prototype.findLastIndex
        

        
          Array.prototype.map
        

        
          Array.prototype.flatMap
        

        
          Array.prototype.reduce
        

        
          Array.prototype.reduceRight
        

        
          Array.prototype.some
        

        
          Array.prototype.sort
        

        
          Array.prototype.toSorted
        
      
    

    
      If there is no return, the callback will implicitly return undefined\`, which may cause unexpected behavior or errors in the code.
    

    
      ```javascript Bad theme={null}
      let arr = ["a", "b", "c"];
      let merged = arr.reduce(function(a, b) {
      a.concat(b); // Noncompliant: No return statement, will result in TypeError
      });
      ```

      ```javascript Fix theme={null}
      let arr = ["a", "b", "c"];
      let merged = arr.reduce(function(a, b) {
      return a.concat(b);
      });
      ```
    
  

  
    
      Unlike strongly typed languages, JavaScript does not enforce a return type on a function. This means that different paths through a function can return different types of values, which can be very confusing to the user and significantly harder to maintain.
    

    
      In particular a function, in JavaScript, will return \`undefined in any of the following cases:
    

    
      
        
          It exits without a return statement.
        

        
          It executes a return\` with no value.
        
      
    

    
      This rule verifies that return values are either always or never specified for each path through a function.
    

    

    
      ```javascript Bad theme={null}
      function foo(a) { // Noncompliant, function exits without "return"
      if (a == 1) {
      return true;
      }
      }
      ```

      ```javascript Fix theme={null}
      function foo(a) {
      if (a == 1) {
      return true;
      }
      return false;
      }
      ```
    
  

  
    
      An assertion is a statement within the unit test that checks whether a particular condition is true or false. It defines the expected behavior of the unit being tested. Assertions are used to express the test’s expected outcome, and they are the criteria against which the actual output of the unit is evaluated.
    

    
      When the unit test is executed, the assertions are evaluated. If all the assertions in the test pass, it means the unit is functioning correctly for that specific set of inputs. If any of the assertions fail, it indicates that there is a problem with the unit’s implementation, and the test case helps identify the issue.
    

    
      Without assertions, a unit test doesn’t actually verify anything, making it ineffective in catching potential bugs or regressions. It will always pass, regardless of the implementation of the unit. This can lead to a false sense of security, as you may believe that your code is working correctly when it might not be.
    

    
      This rule raises an issue when the assertion library chai,sinon or vitest is imported but no assertion is used in a test.
    

    
      ```javascript Bad theme={null}
      const expect = require("chai").expect;

      describe("No assertions", function() {
      it("don't test anything", function() { // Noncompliant: The unit test doesn't assert anything
          const str = "";
      });
      });
      ```

      ```javascript Fix theme={null}
      const expect = require("chai").expect;

      describe("Assertions", function() {
      it("test something", function() {
          const str = "";
          expect(str).to.be.a("string");
      });
      });
      ```
    
  

  
    
      Using regular expression literals is recommended over using the RegExp constructor calls if the pattern is a literal. Regular expression literals are shorter, more readable, and do not need to be escaped like string literals. They can also be more performant because regular expression literals are compiled only once when the script is loaded.
    

    
      ```javascript Bad theme={null}
      new RegExp(/foo/);
      new RegExp('bar');
      new RegExp('baz', 'i');
      new RegExp("\\d+");
      new RegExp(`qux|quuz`);
      ```

      ```javascript Fix theme={null}
      /foo/;
      /bar/;
      /baz/i;
      /\d+/;
      /qux|quuz/;
      new RegExp(`Dear ${title},`);
      ```
    
  

  
    
      JavaScript allows returning a value from a class constructor. This obscure feature is rarely used and is more likely a bug than the developer’s intention.
    

    
      ```javascript Bad theme={null}
      class TextMessage {
      constructor(msg) {
          this.text = msg;
          return msg; // Noncompliant
      }
      }
      ```

      ```javascript Fix theme={null}
      class TextMsg1 {
      constructor(msg) {
          this.text = msg;
      }
      }


      class TextMsg2 {
      constructor(msg) {
          if (!msg) {
              return; // ok to return nothing for flow control
          }
          this.text = msg;
      }
      }
      ```
    
  

  
    
      JavaScript has a prototypal inheritance model. Each object has an internal property that points to another object, called a prototype. That prototype object has a prototype of its own, and the whole sequence is called a prototype chain. When accessing a property or a method of an object, if it is not found at the top level, the search continues through the object’s prototype and then further down the prototype chain. This feature allows for very powerful dynamic inheritance patterns but can also lead to confusion when compared to the classic inheritance.
    

    
      To simplify the access to the prototype of an object some browsers introduced the **proto** property, which was later deprecated and removed from the language. The current ECMAScript standard includes Object.getPrototypeOf and Object.setPrototypeOf static methods that should be used instead of the **proto** property.
    

    
      ```javascript Bad theme={null}
      let prototype = foo.__proto__;  // Noncompliant: use Object.getPrototypeOf
      foo.__proto__ = bar; // Noncompliant: use Object.setPrototypeOf
      ```

      ```javascript Fix theme={null}
      let prototype = Object.getPrototypeOf(foo);
      Object.setPrototypeOf(foo, bar);
      ```
    
  

  
    
      A collection is a data structure that holds multiple values, such as an array or a map. If a collection is declared and populated, but its values are never read anywhere in the code, it can be considered unused code. This can be due to some refactoring, copy-pasting, or typing errors.
    

    
      Unused collections can waste memory usage and slow down the application’s performance. Additionally, they can make the code harder to read and understand, especially for other developers working on the same codebase.
    

    
      ```javascript Bad theme={null}
      function getLength(a, b, c) {
      const strings = [];  // Noncompliant: Array is declared and populated but never read
      strings.push(a);
      strings.push(b);
      strings.push(c);

      return a.length + b.length + c.length;
      }
      ```

      ```javascript Fix theme={null}
      function getLength(a, b, c) {
      return a.length + b.length + c.length;
      }
      ```
    
  

  
    
      Whenever the value property of React context changes, React will rerender the context and all its child nodes and consumers. In JavaScript, things like object literals or function expressions will create a new identity every time they are evaluated. Such constructions should not be directly used as context value because React will always consider they have changed. This can significantly impact performance.
    

    
      ```javascript Bad theme={null}
      function Component() {
      return (
       { /* Noncompliant: value is an object literal */ }
        
      
      );
      }
      ```

      ```javascript Fix theme={null}
      function Component() {
      const obj = useMemo(() => ({foo: 'bar'}), []); // value is cached by useMemo
      return (
       { /* Compliant */ }
        
      
      );
      }
      ```
    
  

  
    
      The finally block is a part of a try…catch…finally statement, which allows you to handle errors and perform cleanup operations regardless of whether an exception is thrown or not. The finally block is executed regardless of whether an exception occurs or not, and it is placed after the try and catch blocks.
    

    
      Having a jump statement, such as return, break, continue, or throw, inside a finally block can lead to unexpected and undesirable behavior, making your code difficult to understand and maintain. While it’s not inherently forbidden to use jump statements in finally blocks, it is generally discouraged for the following reasons:
    

    
      
        
          The primary purpose of the finally block is to ensure cleanup operations and code that must run regardless of the outcome, such as releasing resources or closing connections. If you use a return statement inside the finally block, it will override any previous return statements in the try or catch blocks. This can lead to unexpected values being returned from a function.
        

        
          Jump statements like break, continue, or even another throw inside the finally block can alter the normal control flow of the program. This can make it difficult to reason about the behavior of the code and may introduce subtle bugs that are hard to detect.
        

        
          If a return or throw statement inside the finally block causes a new exception or alters the return value, it can hide or suppress the original exception or return value from the try or catch blocks. This can make it challenging to identify the actual cause of an error.
        

        
          Code that uses jump statements in finally blocks can be hard to read and understand, especially for other developers who might not be familiar with the unusual control flow. Such code can lead to maintenance issues and make it harder to debug and maintain the application in the long run.
        
      
    

    
      This rule reports on all usages of jump statements from a finally block. Even if it’s guaranteed that no unhandled exception can happen in try or catch blocks, it’s not recommended to use any jump statements inside the finally block to have the logic there limited to the "cleanup".
    

    
      ```javascript Bad theme={null}
      async function foo() {
      let result, connection;
      try {
          connection = await connect();
          result = connection.send(1);
      } catch(err) {
          console.error(err.message);
      } finally {
          if (connection) {
              connection.close();
          }
          return result; // Noncompliant: Jump statement 'return' in the 'finally' block
      }
      }
      ```

      ```javascript Fix theme={null}
      async function foo() {
      let result, connection;
      try {
          connection = await connect();
          result = connection.send(1);
      } catch(err) {
          console.error(err.message);
      } finally {
          if (connection) {
              connection.close();
          }
      }
      return result;
      }
      ```
    
  

  
    
      TypeScript allows declaring the type of a function in two different ways:
    

    
      
        
          Function type: () ⇒ number
        

        
          Object type with a call signature: \{ (): number }
        
      
    

    
      The function type syntax is generally preferred for being more concise.
    

    
      ```javascript Bad theme={null}
      function apply(f: { (): string }): string {
      return f();
      }
      ```

      ```javascript Fix theme={null}
      function apply(f: () => string): string {
      return f();
      }
      ```
    
  

  
    
      Web browsers, CDNs or similar proxy-servers can cache HTTP responses (especially large content such as images, scripts etc) to improve web browsing performance and to not overload the application serving the resources. However this may lead to privacy issues if a private web page containing personal user information is cached and served to another user. A different type of attacks allowed when caching resources at the web-browser level is cross-site leak attacks/side-channel attacks, here the attacker infers information about an user (for instance,  web page he is visiting) by observing timing responses or other relevant data when requesting private resources that may be cached.
    

    
      Example of a side channel attack:
    

    
      
        
          The attacker wants to known if a user is involved in a confidential agreement between two companies A and B.
        

        
          If it is the case, the user can access to the resource contract-between-A-and-B.png after being authenticated on a website.
        

        
          The attacker tricks the user to visit a malicious website containing the below code in order to determine the desired information:
        
      
    

    
      
        \`\
        \\`
      
    

    
      ```javascript Bad theme={null}
      const express = require('express');
      const nocache = require('nocache');
      const helmet = require('helmet');

      let app = express();
      app.use(nocache()); // Compliant
      // or
      app.use(helmet.nocache()); // Compliant
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      It is needlessly complex to invert the result of a boolean comparison. The opposite comparison should be made instead.
    

    
      ```javascript Bad theme={null}
      if (!(a === 2)) { ... }  // Noncompliant
      ```

      ```javascript Fix theme={null}
      if (a !== 2) { ... }
      ```
    
  

  
    
      Regular expressions have their own syntax that is understood by regular expression engines. Those engines will throw an exception at runtime if they are given a regular expression that does not conform to that syntax.
    

    
      To avoid syntax errors, special characters should be escaped with backslashes when they are intended to be matched literally and references to capturing groups should use the correctly spelled name or number of the group.
    

    
      ```javascript Bad theme={null}
      new RegExp("([");
      str.match("([");
      ```

      ```javascript Fix theme={null}
      new RegExp("\\(\\[");
      str.match("\\(\\[");
      str.replace("([", "{");
      ```
    
  

  
    
      Operating systems have global directories where any user has write access. Those folders are mostly used as temporary storage areas like \`/tmp in Linux based systems. An application  manipulating files from these folders is exposed to race conditions on filenames: a malicious user can try to create a file with a predictable name before the application does. A successful attack can result in other files being accessed, modified, corrupted or deleted. This risk is even higher if the application runs with elevated permissions.
    

    
      In the past, it has led to the following vulnerabilities:
    

    
      
        
          CVE-2012-2451
        

        
          CVE-2015-1838
        
      
    

    
      This rule raises an issue whenever it detects a hard-coded path to a publicly writable directory like /tmp (see examples bellow). It also detects access to environment variables that point to publicly writable directories, e.g., TMP and TMPDIR.
    

    
      
        
          /tmp
        

        
          /var/tmp
        

        
          /usr/tmp
        

        
          /dev/shm
        

        
          /dev/mqueue
        

        
          /run/lock
        

        
          /var/run/lock
        

        
          /Library/Caches
        

        
          /Users/Shared
        

        
          /private/tmp
        

        
          /private/var/tmp
        

        
          \Windows\Temp
        

        
          \Temp
        

        
          \TMP\`
        
      
    

    
      ```javascript Bad theme={null}
      const tmp = require('tmp');

      const tmpobj = tmp.fileSync(); // Compliant
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      Trailing whitespaces bring no information, they may generate noise when comparing different versions of the same file, and they can create bugs when they appear after a \ marking a line continuation. They should be systematically removed.
    

    
      An automated code formatter allows to completely avoid this family of issues and should be used wherever possible.
    

    
      ```javascript Bad theme={null}
      // The following string will error if there is a whitespace after '\' 
      var str = "Hello \ 
      World";
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.
    

    
      Unresolved directive in \ - include::\{noncompliant}\[]
    

    
      Write one statement per line to improve readability.
    

    
      Unresolved directive in \ - include::\{compliant}\[]
    

    
      ```javascript Bad theme={null}
      foo(); bar(); // Noncompliant
      ```

      ```javascript Fix theme={null}
      foo();
      bar();
      ```
    
  

  
    
      Resource-based policies granting access to all users can lead to information leakage.
    

    
      ```javascript Bad theme={null}
      import { aws_iam as iam } from 'aws-cdk-lib'
      import { aws_s3 as s3 } from 'aws-cdk-lib'

      const bucket = new s3.Bucket(this, "ExampleBucket")

      bucket.addToResourcePolicy(new iam.PolicyStatement({
      effect: iam.Effect.ALLOW,
      actions: ["s3:*"],
      resources: [bucket.arnForObjects("*")],
      principals: [new iam.AnyPrincipal()] // Sensitive
      }))
      ```

      ```javascript Fix theme={null}
      import { aws_iam as iam } from 'aws-cdk-lib'
      import { aws_s3 as s3 } from 'aws-cdk-lib'

      const bucket = new s3.Bucket(this, "ExampleBucket")

      bucket.addToResourcePolicy(new iam.PolicyStatement({
      effect: iam.Effect.ALLOW,
      actions: ["s3:*"],
      resources: [bucket.arnForObjects("*")],
      principals: [new iam.AccountRootPrincipal()]
      }))
      ```
    
  

  
    
      Most of the regular expression engines use backtracking to try all possible execution paths of the regular expression when evaluating an input, in some cases it can cause performance issues, called catastrophic backtracking situations. In the worst case, the complexity of the regular expression is exponential in the size of the input, this means that a small carefully-crafted input (like 20 chars) can trigger catastrophic backtracking and cause a denial of service of the application. Super-linear regex complexity can lead to the same impact too with, in this case, a large carefully-crafted input (thousands chars).
    

    
      This rule determines the runtime complexity of a regular expression and informs you of the complexity if it is not linear.
    

    
      Note that, due to improvements to the matching algorithm, some cases of exponential runtime complexity  have become impossible when run using JDK 9 or later. In such cases, an issue will only be reported if the project’s target Java version is 8 or earlier.
    

    
      ```javascript Bad theme={null}
      /((?=(a+))\2)+$/.test(
      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
      "aaaaaaaaaaaaaaa!"
      ); // Compliant
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      HTTP header referer contains a URL set by web browsers and used by applications to track from where the user came from, it’s for instance a relevant value for web analytic services, but it can cause serious privacy and security problems if the URL contains confidential information. Note that Firefox for instance, to prevent data leaks, removes path information in the Referer header while browsing privately.
    

    
      Suppose an e-commerce website asks the user his credit card number to purchase a product:
    

    
      
        \
        \
        \
        Type your credit card number to purchase products:
        \
        \
        \
        \
      
    

    
      When submitting the above HTML form, a HTTP GET request will be performed, the URL requested will be [https://example.com/valid\_order?cc=1111-2222-3333-4444](https://example.com/valid_order?cc=1111-2222-3333-4444) with credit card number inside and it’s obviously not secure for these reasons:
    

    
      
        
          URLs are stored in the history of browsers.
        

        
          URLs could be accidentally shared when doing copy/paste actions.
        

        
          URLs can be stolen if a malicious person looks at the computer screen of an user.
        
      
    

    
      In addition to these threats, when further requests will be performed from the  "valid\_order" page with a simple legitimate embedded script like that:
    

    
      
        \
      
    

    
      When the victim will visit the website showing the uploaded image, the malicious script embedded into the image will be executed by web browsers performing MIME type sniffing.
    

    
      ```javascript Bad theme={null}
      const express = require('express');
      const helmet= require('helmet');

      let app = express();

      app.use(helmet.noSniff());
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      Amazon Elastic File System (EFS) is a serverless file system that does not require provisioning or managing storage. Stored files can be automatically encrypted by the service. In the case that adversaries gain physical access to the storage medium or otherwise leak a message they are not able to access the data.
    

    
      ```javascript Bad theme={null}
      import { FileSystem } from 'aws-cdk-lib/aws-efs';

      new FileSystem(this, 'unencrypted-explicit', {
      vpc: new Vpc(this, 'VPC'),
      encrypted: false // Sensitive
      });
      ```

      ```javascript Fix theme={null}
      import { CfnFileSystem } from 'aws-cdk-lib/aws-efs';

      new CfnFileSystem(this, 'unencrypted-implicit-cfn', {
      }); // Sensitive as encryption is disabled by default
      ```
    
  

  
    
      Nested control flow statements such as if, for, while, switch, and try are often key ingredients in creating
      what’s known as "Spaghetti code". This code smell can make your program difficult to understand and maintain.
    

    
      When numerous control structures are placed inside one another, the code becomes a tangled, complex web.
      This significantly reduces the code’s readability and maintainability, and it also complicates the testing process.
    

    
      ```javascript Bad theme={null}
      if (condition1) {                  // Compliant - depth = 1
      /* ... */
      if (condition2) {                // Compliant - depth = 2
      /* ... */
      for (let i = 0; i < 10; i++) {  // Compliant - depth = 3
        /* ... */
        if (condition4) {            // Noncompliant - depth = 4, which exceeds the limit
          if (condition5) {          // Depth = 5, exceeding the limit, but issues are only reported on depth = 4
            /* ... */
          }
          return;
        }
      }
      }
      }
      ```

      ```javascript Fix theme={null}
      if (!condition1) {
      return;
      }
      /* ... */
      if (!condition2) {
      return;
      }
      for (let i = 0; i < 10; i++) {
      /* ... */
      if (condition4) {
      if (condition5) {
        /* ... */
      }
      return;
      }
      }
      ```
    
  

  
    
      Nested ternaries are hard to read and can make the order of operations complex to understand.
    

    
      Unresolved directive in \ - include::\{noncompliant}\[]
    

    
      Instead, use another line to express the nested operation in a separate statement.
    

    
      Unresolved directive in \ - include::\{compliant}\[]
    

    
      ```javascript Bad theme={null}
      return (
      <>
      {isLoading ? (
      
      ) : (
      
        {isEditing ? 'Close now' : 'Start now'}
         !saving) : null} />
      
      )}
      
      );
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      When writing code, it is important to ensure that each statement serves a purpose and
      contributes to the overall functionality of the program. When they have no side effects or do not change the control flow, they can either indicate a programming error or be redundant:
    

    
      
        
          The code does not behave as intended: The statements are
          expected to have an effect but they do not. This can be
          caused by mistyping, copy-and-paste errors, etc.
        

        
          The statements are residual after a refactoring.
        
      
    

    
      ```javascript Bad theme={null}
      function getResult() {
      let result = 42;
      if (shouldBeZero()) {
          result == 0; // Noncompliant: no side effect, was an assignment intended?
      }
      return result;
      }
      ```

      ```javascript Fix theme={null}
      var msg = "Hello, "
      "World!"; // Noncompliant; have we forgotten '+' operator on previous line?
      ```
    
  

  
    
      Creating APIs without authentication unnecessarily increases the attack surface on
      the target infrastructure.
    

    
      Unless another authentication method is used, attackers have the
      opportunity to attempt attacks against the underlying API.
      This means attacks both on the functionality provided by the API and its
      infrastructure.
    

    
      ```javascript Bad theme={null}
      import {aws_apigateway as apigateway} from "aws-cdk-lib"

      const resource = api.root.addResource("example")
      resource.addMethod(
      "GET",
      new apigateway.HttpIntegration("https://example.org"),
      {
          authorizationType: apigateway.AuthorizationType.NONE // Sensitive
      }
      )
      ```

      ```javascript Fix theme={null}
      import {aws_apigatewayv2 as apigateway} from "aws-cdk-lib"

      new apigateway.CfnRoute(this, "no-auth", {
      apiId: api.ref,
      routeKey: "GET /no-auth",
      authorizationType: "NONE", // Sensitive
      target: exampleIntegration
      })
      ```
    
  

  
    
      Duplicated string literals make the process of refactoring complex and error-prone, as any change would need to be propagated on all occurrences.
    

    
      ```javascript Bad theme={null}
      function run() {
      prepare("action_to_launch");  // Noncompliant - "action_to_launch" is duplicated 3 times
      execute("action_to_launch");
      release("action_to_launch");
      }

      function printInQuotes(a, b) {
      console.log("'" + a + "'" + b + "'");               // Compliant - literal "'" has less than 10 characters and is excluded
      }
      ```

      ```javascript Fix theme={null}
      var ACTION_1 = "action_to_launch";

      function run() {
      prepare(ACTION_1);                               // Compliant
      execute(ACTION_1);
      release(ACTION_1);
      }
      ```
    
  

  
    
      A function that grows too large tends to aggregate too many responsibilities.
    

    
      Such functions inevitably become harder to understand and therefore harder to maintain.
    

    
      Above a specific threshold, it is strongly advised to refactor into smaller functions which focus on well-defined tasks.
    

    
      Those smaller functions will not only be easier to understand, but also probably easier to test.
    

    
      ```javascript Bad theme={null}
      (function () { // Ignored by this rule

      function open() {  // Classic function declaration; not ignored
      // ...
      }

      function read() {
      // ...
      }

      function readlines() {
      // ...
      }
      })();
      ```

      ```javascript Fix theme={null}
      function Welcome() {
      const greeting = 'Hello, World!';

      // ...

      return (
      
        {greeting}
      
      );
      }
      ```
    
  

  
    
      When the modulus of a negative number is calculated, the result will either be negative or zero. Thus, comparing the modulus of a variable for equality with a positive number (or a negative one) could result in unexpected results.
    

    
      ```javascript Bad theme={null}
      function isOdd(x) {
      return x % 2 == 1;  // Noncompliant; if x is an odd negative, x % 2 == -1
      }
      ```

      ```javascript Fix theme={null}
      function isOdd(int x) {
      return x % 2 != 0;
      }
      ```
    
  

  
    
      Disclosure of version information, usually overlooked by developers but disclosed by default
      by the systems and frameworks in use, can pose a significant security risk
      depending on the production environement.
    

    
      Once this information is public, attackers can use it to identify potential
      security holes or vulnerabilities specific to that version.
    

    
      Furthermore, if the published version information indicates the use of outdated
      or unsupported software, it becomes easier for attackers to exploit known
      vulnerabilities. They can search for published vulnerabilities related to that
      version and launch attacks that specifically target those vulnerabilities.
    

    
      ```javascript Bad theme={null}
      let express = require('express');

      let example = express(); // Sensitive

      example.get('/', function (req, res) {
      res.send('example')
      });
      ```

      ```javascript Fix theme={null}
      let express = require('express');

      let example = express();
      example.disable("x-powered-by");
      ```
    
  

  
    
      Predefined permissions, also known as canned ACLs, are an easy way to grant large privileges to predefined groups or users.
    

    
      The following canned ACLs are security-sensitive:
    

    
      
        
          \`PublicRead, PublicReadWrite grant respectively "read" and "read and write" privileges to everyone in the world (AllUsers group).
        

        
          AuthenticatedRead grants "read" privilege to all authenticated users (AuthenticatedUsers\` group).
        
      
    

    
      ```javascript Bad theme={null}
      const s3 = require('aws-cdk-lib/aws-s3');

      new s3.Bucket(this, 'bucket', {
      accessControl: s3.BucketAccessControl.PUBLIC_READ_WRITE // Sensitive
      });

      new s3deploy.BucketDeployment(this, 'DeployWebsite', {
      accessControl: s3.BucketAccessControl.PUBLIC_READ_WRITE // Sensitive
      });
      ```

      ```javascript Fix theme={null}
      const s3 = require('aws-cdk-lib/aws-s3');

      new s3.Bucket(this, 'bucket', {
      accessControl: s3.BucketAccessControl.PRIVATE
      });

      new s3deploy.BucketDeployment(this, 'DeployWebsite', {
      accessControl: s3.BucketAccessControl.PRIVATE
      });
      ```
    
  

  
    
      The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is, it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2, MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.
    

    
      Consider using safer alternatives, such as SHA-256, SHA-512 or SHA-3.
    

    
      ```javascript Bad theme={null}
      var CryptoJS = require("crypto-js");

      var hash = CryptoJS.MD5("Message");
      ...
      var hash = CryptoJS.SHA1("Message");
      ```

      ```javascript Fix theme={null}
      var hash = CryptoJS.SHA256("Message");
      ```
    
  

  
    
      A value that is incremented or decremented and then not stored is at best wasted code and at worst a bug.
    

    
      ```javascript Bad theme={null}
      function pickNumber() {
      let i = 0;
      i = i++; // Noncompliant; i is still zero

      return i++; // Noncompliant; 0 returned
      }
      ```

      ```javascript Fix theme={null}
      function pickNumber() {
      let i = 0;
      i++;

      return ++i;
      }
      ```
    
  

  
    
      Code is sometimes annotated as deprecated by developers maintaining libraries or APIs to indicate that the method, class, or other programming element is no longer recommended for use. This is typically due to the introduction of a newer or more effective alternative. For example, when a better solution has been identified, or when the existing code presents potential errors or security risks.
    

    
      Deprecation is a good practice because it helps to phase out obsolete code in a controlled manner, without breaking existing software that may still depend on it. It is a way to warn other developers not to use the deprecated element in new code, and to replace it in existing code when possible.
    

    
      Deprecated classes, interfaces, and their members should not be used, inherited or extended because they will eventually be removed. The deprecation period allows you to make a smooth transition away from the aging, soon-to-be-retired technology.
    

    
      Check the documentation or the deprecation message to understand why the code was deprecated and what the recommended alternative is.
    

    
      ```javascript Bad theme={null}
      /**
      * @deprecated Use newFunction instead.
      */
      function oldFunction() {
      console.log("This is the old function.");
      }

      function newFunction() {
      console.log("This is the new function.");
      }
      oldFunction(); // Noncompliant: "oldFunction is deprecated"
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      This rule verifies that single-line comments are not located at the ends of lines of code. The main idea behind this rule is that in order to be really readable, trailing comments would have to be properly written and formatted (correct alignment, no interference with the visual structure of the code, not too long to be visible) but most often, automatic code formatters would not handle this correctly: the code would end up less readable. Comments are far better placed on the previous empty line of code, where they will always be visible and properly formatted.
    

    
      ```javascript Bad theme={null}
      var a1 = b + c; // This is a trailing comment that can be very very long
      ```

      ```javascript Fix theme={null}
      // This very long comment is better placed before the line of code
      var a2 = b + c;
      ```
    
  

  
    
      \{upper\_function}s with a long parameter list are difficult to use because maintainers must figure out the role of each parameter and keep track of their position.
    

    
      Unresolved directive in \ - include::\{language}/noncompliant.adoc\[]
    

    
      The solution can be to:
    

    
      
        
          Split the \{function} into smaller ones
        
      
    

    
      Unresolved directive in \ - include::\{language}/split-example.adoc\[]
    

    
      
        
          Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain
        
      
    

    
      Unresolved directive in \ - include::\{language}/struct-example.adoc\[]
    

    
      This rule raises an issue when a \{function} has more parameters than the provided threshold.
    

    
      ```javascript Bad theme={null}
      class C {
      constructor(
      private param1: number,     // ignored
      param2: boolean,            // counted
      public param3: string,      // ignored
      readonly param4: string[],  // ignored
      param5: number | string     // counted
      ) {} // Compliant by exception
      }
      ```

      ```javascript Fix theme={null}
      import { Component } from '@angular/core';

      @Component({/* ... */})
      class Component {
      constructor(p1, p2, p3, p4, p5) {} // Compliant by exception
      }
      ```
    
  

  
    
      Shared coding conventions allow teams to collaborate efficiently. This rule checks that all function names match a provided regular expression.
    

    
      ```javascript Bad theme={null}
      function DoSomething(){...}
      ```

      ```javascript Fix theme={null}
      function doSomething(){...}
      ```
    
  

  
    
      Two \{func\_name}s having the same implementation are suspicious.
      It might be that something else was intended. Or the duplication is intentional, which becomes a maintenance burden.
    

    
      ```javascript Bad theme={null}
      function calculateCode() {
      doTheThing();
      doOtherThing();
      return code;
      }

      function getName() {  // Noncompliant: duplicates calculateCode
      doTheThing();
      doOtherThing();
      return code;
      }
      ```

      ```javascript Fix theme={null}
      function calculateCode() {
      doTheThing();
      doOtherThing();
      return code;
      }

      function getName() { // Intent is clear
      return calculateCode();
      }
      ```
    
  

  
    
      Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:
    

    
      
        
          CVE-2006-5901
        

        
          CVE-2005-3725
        
      
    

    
      Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:
    

    
      
        
          The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
        

        
          It misleads to use the same address in every environment (dev, sys, qa, prod).
        
      
    

    
      Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.
    

    
      ```javascript Bad theme={null}
      ip = process.env.IP_ADDRESS; // Compliant

      const net = require('net');
      var client = new net.Socket();
      client.connect(80, ip, function() {
      // ...
      });
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately.
      However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code.
      This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase.
      This description explores why this is a problem and how it can be fixed to improve the overall code quality.
    

    
      ```javascript Bad theme={null}
      function doSomething() {
      // TODO
      }
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      Having all branches of a switch or if chain with the same implementation indicates a problem.
    

    
      In the following code:
    

    
      Unresolved directive in \ - include::\{example}\[]
    

    
      Either there is a copy-paste error that needs fixing or an unnecessary switch or if chain that should be removed.
    

    
      ```javascript Bad theme={null}
      if(b == 0) {    //no issue, this could have been done on purpose to make the code more readable
      doSomething();
      } else if(b == 1) {
      doSomething();
      }
      ```

      ```javascript Fix theme={null}
      ```
    
  

  
    
      Overriding a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of code. Further, it could lead maintainers to introduce bugs because they think they’re using one variable but are really using another.
    

    
      ```javascript Bad theme={null}
      function foo() {
      let x = bar(1);
      if (x > 0) {
        let x = bar(2); // Noncompliant
        console.log(x);
      } else {
       console.log("Wrong Value");
      }
      }
      ```

      ```javascript Fix theme={null}
      function foo() {
      let x = bar(1);
      if (x > 0) {
        let y = bar(2);
        console.log(y);
      } else {
       console.log("Wrong Value");
      }
      }
      ```
    
  

  
    
      A mixed-content is when a resource is loaded with the HTTP protocol, from a website accessed with the HTTPs protocol, thus mixed-content are not encrypted and exposed to MITM attacks and could break the entire level of protection that was desired by implementing encryption with the HTTPs protocol.
    

    
      The main threat with mixed-content is not only the confidentiality of resources but the whole website integrity:
    

    
      
        
          A passive mixed-content (eg: \) allows an attacker to access and replace only these resources, like images, with malicious ones that could lead to successful phishing attacks.
        

        
          With active mixed-content (eg: \ \
        \ \
        \

Hello {{name}}

Your language is {language}!

Your language is {language}!

Your language is {language}!

Your language is {language}!

{ props.name }

{ props.name || getDefaultName() }

{ props.username }

{ props.username }

Hello

Hello {this.props.name}