@ngxr/rules NPM

@ngxr/rules

Angular Resources rules to enforce a consistent code style for development.

Rules

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Class and Member design

Member overloads SHOULD be consecutive to improve readability and organization by grouping naturally related items together.

"adjacent-overload-signatures": true

Getters and setters SHOULD access the expected fields. A setter should update the field with the corresponding name, and a getter should access the field with the corresponding name. SonarTS.

"no-accessor-field-mismatch": true

Function design

Functions SHOULD NOT have too many lines of code. If it does, tends to aggregate too many responsibilities, making them harder to understand and therefore harder to maintain. SonarTS, Angular.

"no-big-function": [true, 75]

Arrow lambdas SHOULD prefer return as () => x over () => { return x; }. It’s unnecessary to include return and {} brackets in arrow lambdas. Leaving them out results in simpler and easier to read code.

"arrow-return-shorthand": true

Strings

String literals SHOULD not be duplicated. SonarTS.

"no-duplicate-string": [true, 2]

Collections

Arrays SHOULD be defined as type[] instead of Array<type> to improve consistency throughout the code.

"array-type": [true, "array"]

Collections elements SHOULD NOT be overwritten unconditionally. SonarTS

"no-element-overwrite": true

delete SHOULD NOT be used on arrays. The delete operator can be used with arrays, but if it is, a hole will be left in the array because the indexes/keys won't be shifted to reflect the deletion. Use splice, pop or shift instead. SonarTS.

"no-array-delete": true

Collection sizes and array length comparisons SHOULD make sense. The size of a collection and the length of an array are always greater than or equal to zero. Perhaps the intent was to check the non-emptiness of the collection or array instead. SonarTS.

"no-collection-size-mischeck": true

Conditional structures

Two branches in a conditional structure SHOULD NOT have exactly the same implementation. SonarTS

"no-duplicated-branches": true

All branches in a conditional structure SHOULD NOT have exactly the same implementation. SonarTS.

"no-all-duplicated-branches": true

Logical OR (||) SHOULD NOT be used in switch cases. Only the first argument will be considered at execution time. SonarTS.

"no-case-with-or": true

Possible errors / Bug Detection

SHOULD NOT use eval(), because opens up your code for injection attacks, debugging can be more challenging and eval'd code executes slower. ESLint.

"ban": [
  true,
  { "name": "eval", "message": "eval() is B.A.D." }
]

Best practices / Code Smell

Cognitive Complexity SHOULD NOT be too high. It is a measure of how hard the control flow of a function is to understand. Functions with high Cognitive Complexity will be difficult to maintain. SonarTS.

"cognitive-complexity": [true, 15]

The Cyclomatic Complexity of functions SHOULD NOT exceed a defined threshold. Complex code may perform poorly and can be difficult to test thoroughly. SonarTS, ESLint.

"mccabe-complexity": [true, 15]

Dead stores SHOULD be removed. A dead store happens when a local variable is assigned a value that is not read by any subsequent instruction or when an object property is assigned a value that is not subsequently used. SonarTS.

"no-dead-store": [true, 15]

Comments and documentation

Sections of code SHOULD NOT be commented out. Unused code should be deleted and can be retrieved from source control history if required. SonarTS.