Similar blocks of code found in 2 locations. Consider refactoring. Open
this.citation = this.configuration.citation.reduce((map, obj) => {
map.set(obj.key, obj);
return map;
}, new Map());
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 47.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Similar blocks of code found in 2 locations. Consider refactoring. Open
this.configuration.criteria.reduce((map, obj) => {
map.set(obj.id, obj);
return map;
},
new Map())
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 47.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
if statements must be braced Open
if (isNullOrUndefined(markdown)) return null;
- Read upRead up
- Exclude checks
Rule: curly
Enforces braces for if
/for
/do
/while
statements.
Rationale
if (foo === bar)
foo++;
bar++;
In the code above, the author almost certainly meant for both foo++
and bar++
to be executed only if foo === bar
. However, they forgot braces and bar++
will be executed
no matter what. This rule could prevent such a mistake.
Notes
- Has Fix
Config
One of the following options may be provided:
-
"as-needed"
forbids any unnecessary curly braces. -
"ignore-same-line"
skips checking braces for control-flow statements that are on one line and start on the same line as their control-flow keyword
Examples
"curly": true
"curly": true,ignore-same-line
"curly": true,as-needed
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"as-needed",
"ignore-same-line"
]
}
}
For more information see this page.
Shadowed name: 'key' Open
criteriaData.labelArray = Array.from(criteriaData.labels).map(([key, value]) => value);
- Read upRead up
- Exclude checks
Rule: no-shadowed-variable
Disallows shadowing variable declarations.
Rationale
When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers. Compare the following snippets:
const a = 'no shadow';
function print() {
console.log(a);
}
print(); // logs 'no shadow'.
const a = 'no shadow';
function print() {
const a = 'shadow'; // TSLint will complain here.
console.log(a);
}
print(); // logs 'shadow'.
ESLint has an equivalent rule. For more background information, refer to this MDN closure doc.
Config
You can optionally pass an object to disable checking for certain kinds of declarations.
Possible keys are "class"
, "enum"
, "function"
, "import"
, "interface"
, "namespace"
, "typeAlias"
and "typeParameter"
. You can also pass "underscore
" to ignore variable names that begin with _
.
Just set the value to false
for the check you want to disable.
All checks default to true
, i.e. are enabled by default.
Note that you cannot disable variables and parameters.
The option "temporalDeadZone"
defaults to true
which shows errors when shadowing block scoped declarations in their
temporal dead zone. When set to false
parameters, classes, enums and variables declared
with let
or const
are not considered shadowed if the shadowing occurs within their
temporal dead zone.
The following example shows how the "temporalDeadZone"
option changes the linting result:
function fn(value) {
if (value) {
const tmp = value; // no error on this line if "temporalDeadZone" is false
return tmp;
}
let tmp = undefined;
if (!value) {
const tmp = value; // this line always contains an error
return tmp;
}
}
Examples
"no-shadowed-variable": true
"no-shadowed-variable": true,[object Object]
Schema
{
"type": "object",
"properties": {
"class": {
"type": "boolean"
},
"enum": {
"type": "boolean"
},
"function": {
"type": "boolean"
},
"import": {
"type": "boolean"
},
"interface": {
"type": "boolean"
},
"namespace": {
"type": "boolean"
},
"typeAlias": {
"type": "boolean"
},
"typeParameter": {
"type": "boolean"
},
"temporalDeadZone": {
"type": "boolean"
},
"underscore": {
"type": "boolean"
}
}
}
For more information see this page.
Declaration of static method not allowed after declaration of instance method. Instead, this should come after instance fields. Open
static getHtml(converter: Showdown.Converter, citation: Map<string, Citation>, markdown: string): string {
if (isNullOrUndefined(markdown)) return null;
return ConfigurationService.converter.makeHtml(markdown.toString()).replace(/(?:\[@)([^\]]*)(?:\])/g, (match, dec) => {
if (citation.has(dec)) {
return '<a class="cite-link" href="#' + dec + '">[' + citation.get(dec).index + ']</a>';
- Read upRead up
- Exclude checks
Rule: member-ordering
Enforces member ordering.
Rationale
A consistent ordering for class members can make classes easier to read, navigate, and edit.
A common opposite practice to member-ordering
is to keep related groups of classes together.
Instead of creating classes with multiple separate groups, consider splitting class responsibilities
apart across multiple single-responsibility classes.
Notes
- Has Fix
Config
One argument, which is an object, must be provided. It should contain an order
property.
The order
property should have a value of one of the following strings:
fields-first
instance-sandwich
statics-first
fields-first
puts, in order of precedence:
* fields before constructors before methods
* static members before instance members
* public members before protected members before private members
instance-sandwich
puts, in order of precedence:
* fields before constructors before methods
* static fields before instance fields, but static methods after instance methods
* public members before protected members before private members
statics-first
puts, in order of precedence:
* static members before instance members
* public members before protected members before private members
* fields before methods
* instance fields before constructors before instance methods
* fields before constructors before methods
* public members before protected members before private members
Note that these presets, despite looking similar, can have subtly different behavior due to the order in which these
rules are specified. A fully expanded ordering can be found in the PRESETS constant in
https://github.com/palantir/tslint/blob/master/src/rules/memberOrderingRule.ts.
(You may need to check the version of the file corresponding to your version of tslint.)
Alternatively, the value for order
may be an array consisting of the following strings:
public-static-field
protected-static-field
private-static-field
public-static-method
private-static-method
protected-static-method
public-instance-field
protected-instance-field
private-instance-field
public-constructor
protected-constructor
private-constructor
public-instance-method
protected-instance-method
private-instance-method
public-static-accessor
protected-static-accessor
private-static-accessor
public-instance-accessor
protected-instance-accessor
private-instance-accessor
You can also omit the access modifier to refer to "public-", "protected-", and "private-" all at once; for example, "static-field".
You can also make your own categories by using an object instead of a string:
{
"name": "static non-private",
"kinds": [
"public-static-field",
"protected-static-field",
"public-static-method",
"protected-static-method"
]
}
The 'alphabetize' option will enforce that members within the same category should be alphabetically sorted by name. Computed property names are sorted before others but not sorted amongst each other. Additionally getters will be sorted before setters (after alphabetization).
Examples
"member-ordering": true,[object Object]
"member-ordering": true,[object Object]
"member-ordering": true,[object Object]
Schema
{
"type": "object",
"properties": {
"alphabetize": {
"type": "boolean"
},
"order": {
"oneOf": [
{
"type": "string",
"enum": [
"fields-first",
"instance-sandwich",
"statics-first"
]
},
{
"type": "array",
"items": {
"type": "string",
"enum": [
"public-static-field",
"protected-static-field",
"private-static-field",
"public-static-method",
"private-static-method",
"protected-static-method",
"public-instance-field",
"protected-instance-field",
"private-instance-field",
"public-constructor",
"protected-constructor",
"private-constructor",
"public-instance-method",
"protected-instance-method",
"private-instance-method",
"public-static-accessor",
"protected-static-accessor",
"private-static-accessor",
"public-instance-accessor",
"protected-instance-accessor",
"private-instance-accessor"
]
},
"maxLength": 13
}
]
}
},
"additionalProperties": false
}
For more information see this page.
Declaration of static method not allowed after declaration of instance method. Instead, this should come after instance fields. Open
static getLatex(converter: Showdown.Converter, text: string): string {
if (isNullOrUndefined(text)) {
return null;
}
return ConfigurationService.converter.makeHtml(text.toString()).replace(/(?:\[@)([^\]]*)(?:\])/g, (match, dec) => {
- Read upRead up
- Exclude checks
Rule: member-ordering
Enforces member ordering.
Rationale
A consistent ordering for class members can make classes easier to read, navigate, and edit.
A common opposite practice to member-ordering
is to keep related groups of classes together.
Instead of creating classes with multiple separate groups, consider splitting class responsibilities
apart across multiple single-responsibility classes.
Notes
- Has Fix
Config
One argument, which is an object, must be provided. It should contain an order
property.
The order
property should have a value of one of the following strings:
fields-first
instance-sandwich
statics-first
fields-first
puts, in order of precedence:
* fields before constructors before methods
* static members before instance members
* public members before protected members before private members
instance-sandwich
puts, in order of precedence:
* fields before constructors before methods
* static fields before instance fields, but static methods after instance methods
* public members before protected members before private members
statics-first
puts, in order of precedence:
* static members before instance members
* public members before protected members before private members
* fields before methods
* instance fields before constructors before instance methods
* fields before constructors before methods
* public members before protected members before private members
Note that these presets, despite looking similar, can have subtly different behavior due to the order in which these
rules are specified. A fully expanded ordering can be found in the PRESETS constant in
https://github.com/palantir/tslint/blob/master/src/rules/memberOrderingRule.ts.
(You may need to check the version of the file corresponding to your version of tslint.)
Alternatively, the value for order
may be an array consisting of the following strings:
public-static-field
protected-static-field
private-static-field
public-static-method
private-static-method
protected-static-method
public-instance-field
protected-instance-field
private-instance-field
public-constructor
protected-constructor
private-constructor
public-instance-method
protected-instance-method
private-instance-method
public-static-accessor
protected-static-accessor
private-static-accessor
public-instance-accessor
protected-instance-accessor
private-instance-accessor
You can also omit the access modifier to refer to "public-", "protected-", and "private-" all at once; for example, "static-field".
You can also make your own categories by using an object instead of a string:
{
"name": "static non-private",
"kinds": [
"public-static-field",
"protected-static-field",
"public-static-method",
"protected-static-method"
]
}
The 'alphabetize' option will enforce that members within the same category should be alphabetically sorted by name. Computed property names are sorted before others but not sorted amongst each other. Additionally getters will be sorted before setters (after alphabetization).
Examples
"member-ordering": true,[object Object]
"member-ordering": true,[object Object]
"member-ordering": true,[object Object]
Schema
{
"type": "object",
"properties": {
"alphabetize": {
"type": "boolean"
},
"order": {
"oneOf": [
{
"type": "string",
"enum": [
"fields-first",
"instance-sandwich",
"statics-first"
]
},
{
"type": "array",
"items": {
"type": "string",
"enum": [
"public-static-field",
"protected-static-field",
"private-static-field",
"public-static-method",
"private-static-method",
"protected-static-method",
"public-instance-field",
"protected-instance-field",
"private-instance-field",
"public-constructor",
"protected-constructor",
"private-constructor",
"public-instance-method",
"protected-instance-method",
"private-instance-method",
"public-static-accessor",
"protected-static-accessor",
"private-static-accessor",
"public-instance-accessor",
"protected-instance-accessor",
"private-instance-accessor"
]
},
"maxLength": 13
}
]
}
},
"additionalProperties": false
}
For more information see this page.