no-alert
alert
, confirm
, and prompt
alert
, confirm
, and prompt
methods that are considered disruptive for the user experience. These methods halt webpage execution and do not provide customization options, leading to a poor user interface.no-caller
arguments.caller
or arguments.callee
arguments.caller
and arguments.callee
, which are both deprecated in ES5 strict mode and considered bad practice in modern JavaScript development. Their use can lead to optimization issues and make code difficult to manage, especially in strict mode where their use will throw an error.
arguments.caller
and arguments.callee
, the rule encourages the use of named functions or other modern alternatives, which can lead to more readable and maintainable code. For example, converting a recursive anonymous function to a named function improves stack traces in error messages and makes the code more understandable.
no-console
console
console.log
method.console
methods, ensuring that alternatives like centralized logging solutions are considered and implemented.no-debugger
debugger
debugger
statement in JavaScript code. This is beneficial because leaving debugger
statements in production code can inadvertently halt the execution of JavaScript in browsers that have developer tools open, leading to a poor user experience.
debugger
statement, thus enforcing best practices without requiring manual intervention by the developer. This automation helps in maintaining code quality and saving time during development and code review processes.
debugger
statements, this rule helps enforce a coding standard across the development team that prioritizes the use of other debugging methods, such as logging to the console or using modern development tools and breakpoints. This standardization helps in creating a consistent debugging approach within a project, making the code more maintainable and understandable for all team members.
no-eq-null
null
comparisons without type-checking operators===
) with null
, making sure the check distinguishes between null
and undefined
values explicitly. In JavaScript, ==
null matches both null
and undefined
, which can lead to unintended consequences if the distinction matters in the code logic.
null
, the rule aids in promoting coding best practices that improve the predictability and readability of the code. This can be particularly useful in codebases where null
and undefined
are used with specific and distinct meanings.
== null
), which could inadvertently pass both null
and undefined
values. This is especially important in situations where only one of these values (null
or undefined
) is considered valid, or they trigger different behaviors.
no-new-symbol
new
operators with the Symbol
objectSymbol
correctly without the new
keyword prevents runtime errors, because Symbol
is not a constructor. The ES6 Symbol
object should be instantiated without new
. Using new
with Symbol
will throw a TypeError, so this rule helps to catch such errors during the linting phase instead of at runtime.new
operators with the Symbol
object, the rule promotes the use of ES6 features according to their specification. This adherence not only ensures code correctness but also enhances readability and maintains consistency across codebases that utilize modern JavaScript features.new
for creating instances is more common. It serves as an educational tool that guides them towards the correct usage of Symbol
, aligning their coding practices with standard JavaScript idioms.new Symbol()
is incorrectly used, this rule not only flags potential code issues but also offers a quick resolution path. This reduces the manual effort required to correct such mistakes and accelerates the development process, ensuring more efficient code refactoring and maintenance.no-plusplus
++
and --
++
and --
, which encourages the use of += 1
or -= 1
instead. This approach can make the code clearer, especially for those not familiar with the unary operators or coming from languages where these operators are not used or behave differently.+= 1
or -= 1
is less prone to misinterpretation or misuse.++
and --
operators might be overlooked or misunderstood, whereas += 1
and -= 1
explicitly state the operation’s intent.++
and --
in favor of += 1
and -= 1
can align better with patterns that avoid modifying data in place. This can lead to code that’s easier to reason about in terms of data flow and state changes.no-proto
__proto__
property__proto__
property, which is a deprecated and non-standard feature for setting an object’s prototype. Using __proto__
can lead to compatibility and security issues in JavaScript code, making the enforcement of this rule crucial for maintaining code quality and ensuring cross-browser compatibility.
Object.create
as a recommended approach for prototype chaining. This method is part of the ECMAScript standard and provides a clearer and more secure way to set up prototype chains, allowing for the definition of additional properties at the time of object creation. This practice leads to code that is both safer and more aligned with modern JavaScript development standards.
__proto__
property can be accessed and modified through user input in some cases, blocking its usage reduces the surface area for attackers aiming to manipulate an application’s object prototype, leading to potentially severe security risks.
Object.create
and the explicit definition of properties, developers are nudged towards a more thoughtful design, potentially improving code readability and maintainability by explicitly defining inheritance and property characteristics.
no-prototype-builtins
Object.prototype
methods directly on objectsObject.prototype
methods, leading to unexpected bugs when methods like hasOwnProperty
are called directly on objects.Object.prototype
methods and using them with call
or apply
, thereby ensuring that the check is always performed against the object’s properties, not its methods.Object.prototype
methods directly on user-supplied objects, which could be manipulated to cause unexpected behavior or denial-of-service attacks by creating objects with properties like hasOwnProperty
.no-throw-literal
name
and message
, and allow for further customization. This is in contrast to literals, which are limited in the scope of information they convey.try/catch
blocks to catch specific types of errors based on their properties.no-unused-vars
filename
, sourceCode
, settings
, and options
, which allows for a more tailored and contextual analysis of the code. This specificity enables the rule to be adaptable to different environments and project settings, ensuring that it can be effectively applied across a wide range of projects with varying configurations.
autofix/no-unused-vars
) suggests that not only does the rule identify unused variables, but it also potentially offers a fix to automatically remove such variables. This automation can save developers time and effort in manual code clean-up, accelerating the development process while simultaneously enforcing code quality standards. This is particularly advantageous in large codebases where manually identifying and removing unused variables can be tedious and prone to human error.
no-useless-catch
catch
clausescatch
clauses that merely rethrow the caught error without handling it, leading to cleaner and more readable code. As seen in the example, the catch block doesn’t perform any error handling and directly throws the caught error, making it unnecessary.
catch
clauses, it reduces the potential for mistaken error handling. Developers might leave such clauses with the intention to add error handling later but forget. This rule ensures that only meaningful error handling is present.
catch
clause, it prompts the developer to consider whether they should be handling the error in a specific way or if the error can be allowed to propagate without catching.
no-useless-concat
prefer-spread
.apply()
...
) instead of the .apply()
method, as enforced by this rule, makes the code more succinct and readable. The spread syntax is often more intuitive to understand at a glance, especially for developers who might not be as familiar with the .apply()
method’s purpose and usage.
.apply()
, the rule helps maintain consistency in how functions are called and arguments are passed within a codebase. Consistent coding practices make the code easier to read, maintain, and debug by ensuring that similar tasks are accomplished in similar ways.
.apply()
call because it does not have the overhead of setting up a function context when calling .apply()
.
autofix/prefer-spread
rule indirectly encourages developers to use modern JavaScript features, keeping the codebase up-to-date with the latest ECMAScript standards. The spread operator was introduced in ES6 (ECMAScript 2015), and adopting such features may promote the use of other modern JavaScript practices and syntax, contributing to a more modern and efficient codebase.
radix
parseInt()
parseInt()
function is consistently used with a radix argument, which makes code more predictable by explicitly stating the numeric base that should be used for the conversion process. Without specifying the radix, parseInt()
might lead to unexpected behavior depending on the input string’s format, making the codebase less reliable.
parseInt()
interprets strings with leading zeros as octal numbers. This is particularly important when dealing with user input or data that might not always conform to a single format.
parseInt()
, reducing the time spent on understanding code semantics.
parseInt()
across all instances. This reduces the cognitive load for developers who work on the codebase, as they can expect a consistent pattern when dealing with numerical string conversion, leading to fewer mistakes and quicker code reviews.
valid-typeof
typeof
expressions against valid stringstypeof
operator by enforcing comparisons against a set of predefined valid strings, such as “undefined”, “object”, “boolean”, “number”, “string”, “function”, and “symbol”. Comparing the result of typeof
to an incorrect string, such as “integer” in the example, could lead to unexpected behavior or bugs in the code that are difficult to trace.
typeof
for type checking. By ensuring that only valid strings are compared against the typeof
operator’s results, the code is more readable, maintainable, and less prone to typos or misunderstandings regarding JavaScript’s types.
typeof
, it sidesteps unnecessary conditionals or incorrect branches in logic that could otherwise lead to performance inefficiencies or more complex logic than needed. This preemptive correction leads to more optimized and straightforward code execution paths.