Function getService
has 54 lines of code (exceeds 25 allowed). Consider refactoring. Open
Reporter.prototype.getService = function(serviceId, callback){
var storage = this.storage;
debug('loading service');
Function 'getUptime' has a complexity of 7. Open
function getUptime (service, outages, currentOutage, since) {
- Read upRead up
- Exclude checks
Limit Cyclomatic Complexity (complexity)
Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.
function a(x) {
if (true) {
return x; // 1st path
} else if (false) {
return x+1; // 2nd path
} else {
return 4; // 3rd path
}
}
Rule Details
This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20
).
Examples of incorrect code for a maximum of 2:
/*eslint complexity: ["error", 2]*/
function a(x) {
if (true) {
return x;
} else if (false) {
return x+1;
} else {
return 4; // 3rd path
}
}
Examples of correct code for a maximum of 2:
/*eslint complexity: ["error", 2]*/
function a(x) {
if (true) {
return x;
} else {
return 4;
}
}
Options
Optionally, you may specify a max
object property:
"complexity": ["error", 2]
is equivalent to
"complexity": ["error", { "max": 2 }]
Deprecated: the object property maximum
is deprecated. Please use the property max
instead.
When Not To Use It
If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.
Further Reading
Related Rules
- [max-depth](max-depth.md)
- [max-len](max-len.md)
- [max-nested-callbacks](max-nested-callbacks.md)
- [max-params](max-params.md)
- [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/
Function getGeneralServiceInfo
has 35 lines of code (exceeds 25 allowed). Consider refactoring. Open
function getGeneralServiceInfo(service, storage, callback) {
storage.getCurrentOutage(service, function(err, currentOutage){
if (err) {
return callback(err);
Function getUptime
has 32 lines of code (exceeds 25 allowed). Consider refactoring. Open
function getUptime (service, outages, currentOutage, since) {
var totalDownTime = 0;
var now = +new Date();
Function getUptime
has a Cognitive Complexity of 8 (exceeds 5 allowed). Consider refactoring. Open
function getUptime (service, outages, currentOutage, since) {
var totalDownTime = 0;
var now = +new Date();
- Read upRead up
Cognitive Complexity
Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.
A method's cognitive complexity is based on a few simple rules:
- Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
- Code is considered more complex for each "break in the linear flow of the code"
- Code is considered more complex when "flow breaking structures are nested"
Further reading
Expected error to be handled. Open
storage.getServices(options, function(err, services){
- Read upRead up
- Exclude checks
Enforce Callback Error Handling (handle-callback-err)
In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern.
This pattern expects an Error
object or null
as the first argument of the callback.
Forgetting to handle these errors can lead to some really strange behavior in your application.
function loadData (err, data) {
doSomething(); // forgot to handle error
}
Rule Details
This rule expects that when you're using the callback pattern in Node.js you'll handle the error.
Options
The rule takes a single string option: the name of the error parameter. The default is "err"
.
Examples of incorrect code for this rule with the default "err"
parameter name:
/*eslint handle-callback-err: "error"*/
function loadData (err, data) {
doSomething();
}
Examples of correct code for this rule with the default "err"
parameter name:
/*eslint handle-callback-err: "error"*/
function loadData (err, data) {
if (err) {
console.log(err.stack);
}
doSomething();
}
function generateError (err) {
if (err) {}
}
Examples of correct code for this rule with a sample "error"
parameter name:
/*eslint handle-callback-err: ["error", "error"]*/
function loadData (error, data) {
if (error) {
console.log(error.stack);
}
doSomething();
}
regular expression
Sometimes (especially in big projects) the name of the error variable is not consistent across the project, so you need a more flexible configuration to ensure that the rule reports all unhandled errors.
If the configured name of the error variable begins with a ^
it is considered to be a regexp pattern.
- If the option is
"^(err|error|anySpecificError)$"
, the rule reports unhandled errors where the parameter name can beerr
,error
oranySpecificError
. - If the option is
"^.+Error$"
, the rule reports unhandled errors where the parameter name ends withError
(for example,connectionError
orvalidationError
will match). - If the option is
"^.*(e|E)rr"
, the rule reports unhandled errors where the parameter name matches any string that containserr
orErr
(for example,err
,error
,anyError
,some_err
will match).
When Not To Use It
There are cases where it may be safe for your application to ignore errors, however only ignore errors if you are confident that some other form of monitoring will help you catch the problem.