Unexpected console statement. Open
console.log(error);
- Read upRead up
- Exclude checks
disallow the use of console
(no-console)
In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console
. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console
should be stripped before being pushed to production.
console.log("Made it here.");
console.error("That shouldn't have happened.");
Rule Details
This rule disallows calls to methods of the console
object.
Examples of incorrect code for this rule:
/*eslint no-console: "error"*/
console.log("Log a debug level message.");
console.warn("Log a warn level message.");
console.error("Log an error level message.");
Examples of correct code for this rule:
/*eslint no-console: "error"*/
// custom console
Console.log("Hello world!");
Options
This rule has an object option for exceptions:
-
"allow"
has an array of strings which are allowed methods of theconsole
object
Examples of additional correct code for this rule with a sample { "allow": ["warn", "error"] }
option:
/*eslint no-console: ["error", { allow: ["warn", "error"] }] */
console.warn("Log a warn level message.");
console.error("Log an error level message.");
When Not To Use It
If you're using Node.js, however, console
is used to output information to the user and so is not strictly used for debugging purposes. If you are developing for Node.js then you most likely do not want this rule enabled.
Related Rules
- [no-alert](no-alert.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype. Open
for (let key in data) {
- Read upRead up
- Exclude checks
Require Guarding for-in (guard-for-in)
Looping over objects with a for in
loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.
for (key in foo) {
doSomething(key);
}
Note that simply checking foo.hasOwnProperty(key)
is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).
Rule Details
This rule is aimed at preventing unexpected behavior that could arise from using a for in
loop without filtering the results in the loop. As such, it will warn when for in
loops do not filter their results with an if
statement.
Examples of incorrect code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
doSomething(key);
}
Examples of correct code for this rule:
/*eslint guard-for-in: "error"*/
for (key in foo) {
if (Object.prototype.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
if ({}.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
}
Related Rules
- [no-prototype-builtins](no-prototype-builtins.md)
Further Reading
The Function constructor is eval. Open
let func = new Function(...dataKeys, "return `" + literal + "`;");
- Read upRead up
- Exclude checks
Disallow Function Constructor (no-new-func)
It's possible to create functions in JavaScript using the Function
constructor, such as:
var x = new Function("a", "b", "return a + b");
This is considered by many to be a bad practice due to the difficulty in debugging and reading these types of functions.
Rule Details
This error is raised to highlight the use of a bad practice. By passing a string to the Function constructor, you are requiring the engine to parse that string much in the way it has to when you call the eval
function.
Examples of incorrect code for this rule:
/*eslint no-new-func: "error"*/
var x = new Function("a", "b", "return a + b");
var x = Function("a", "b", "return a + b");
Examples of correct code for this rule:
/*eslint no-new-func: "error"*/
var x = function (a, b) {
return a + b;
};
When Not To Use It
In more advanced cases where you really need to use the Function
constructor.
Source: http://eslint.org/docs/rules/