A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:
Foo.prototype.bar=functionbar(){};
Adding the second bar in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.
Rule Details
This rule can enforce or disallow the use of named function expressions.
Options
This rule has a string option:
"always" (default) requires function expressions to have a name
"as-needed" requires function expressions to have a name, if the name isn't assigned automatically per the ECMAScript specification.
"never" disallows named function expressions, except in recursive functions, where a name is needed
This rule has an object option:
"generators": "always" | "as-needed" | "never"
"always" require named generators
"as-needed" require named generators if the name isn't assigned automatically per the ECMAScript specification.
"never" disallow named generators where possible.
When a value for generators is not provided the behavior for generator functions falls back to the base option.
Please note that "always" and "as-needed" require function expressions and function declarations in export default declarations to have a name.
always
Examples of incorrect code for this rule with the default "always" option:
::: incorrect
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar=function(){};
const cat ={
meow:function(){}
}
(function(){
// ...
}())
exportdefaultfunction(){}
:::
Examples of correct code for this rule with the default "always" option:
::: correct
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar=functionbar(){};
const cat ={
meow(){}
}
(functionbar(){
// ...
}())
exportdefaultfunctionfoo(){}
:::
as-needed
ECMAScript 6 introduced a name property on all functions. The value of name is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name property equal to the name of the variable. The value of name is then used in stack traces for easier debugging.
Examples of incorrect code for this rule with the "as-needed" option:
::: incorrect
/*eslint func-names: ["error", "as-needed"]*/
Foo.prototype.bar=function(){};
(function(){
// ...
}())
exportdefaultfunction(){}
:::
Examples of correct code for this rule with the "as-needed" option:
::: correct
/*eslint func-names: ["error", "as-needed"]*/
varbar=function(){};
const cat ={
meow:function(){}
}
classC{
#bar=function(){};
baz=function(){};
}
quux ??=function(){};
(functionbar(){
// ...
}())
exportdefaultfunctionfoo(){}
:::
never
Examples of incorrect code for this rule with the "never" option:
::: incorrect
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar=functionbar(){};
(functionbar(){
// ...
}())
:::
Examples of correct code for this rule with the "never" option:
::: correct
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar=function(){};
(function(){
// ...
}())
:::
generators
Examples of incorrect code for this rule with the "always", { "generators": "as-needed" } options:
ECMAScript 6 provides a concise form for defining object literal methods and properties. This
syntax can make defining complex object literals much cleaner.
Here are a few common examples using the ES5 syntax:
// properties
var foo ={
x: x,
y: y,
z: z,
};
// methods
var foo ={
a:function(){},
b:function(){}
};
Now here are ES6 equivalents:
/*eslint-env es6*/
// properties
var foo ={x, y, z};
// methods
var foo ={
a(){},
b(){}
};
Rule Details
This rule enforces the use of the shorthand syntax. This applies
to all methods (including generators) defined in object literals and any
properties defined where the key name matches name of the assigned variable.
Each of the following properties would warn:
/*eslint object-shorthand: "error"*/
/*eslint-env es6*/
var foo ={
w:function(){},
x:function*(){},
[y]:function(){},
z: z
};
In that case the expected syntax would have been:
/*eslint object-shorthand: "error"*/
/*eslint-env es6*/
var foo ={
w(){},
*x(){},
[y](){},
z
};
This rule does not flag arrow functions inside of object literals.
The following will not warn:
/*eslint object-shorthand: "error"*/
/*eslint-env es6*/
var foo ={
x:(y)=> y
};
Options
The rule takes an option which specifies when it should be applied. It can be set to one of the following values:
"always" (default) expects that the shorthand will be used whenever possible.
"methods" ensures the method shorthand is used (also applies to generators).
"properties" ensures the property shorthand is used (where the key and variable name match).
"never" ensures that no property or method shorthand is used in any object literal.
"consistent" ensures that either all shorthand or all long-form will be used in an object literal.
"consistent-as-needed" ensures that either all shorthand or all long-form will be used in an object literal, but ensures all shorthand whenever possible.
You can set the option in configuration like this:
{
"object-shorthand": ["error", "always"]
}
Additionally, the rule takes an optional object configuration:
"avoidQuotes": true indicates that long-form syntax is preferred whenever the object key is a string literal (default: false). Note that this option can only be enabled when the string option is set to "always", "methods", or "properties".
"ignoreConstructors": true can be used to prevent the rule from reporting errors for constructor functions. (By default, the rule treats constructors the same way as other functions.) Note that this option can only be enabled when the string option is set to "always" or "methods".
"methodsIgnorePattern" (string) for methods whose names match this regex pattern, the method shorthand will not be enforced. Note that this option can only be used when the string option is set to "always" or "methods".
"avoidExplicitReturnArrows": true indicates that methods are preferred over explicit-return arrow functions for function properties. (By default, the rule allows either of these.) Note that this option can only be enabled when the string option is set to "always" or "methods".
Anyone not yet in an ES6 environment would not want to apply this rule. Others may find the terseness of the shorthand
syntax harder to read and may not want to encourage it with this rule.
Source: http://eslint.org/docs/rules/