ZiftSolutions TSlint

Table of contents:

• Getting started
  • Installation
• Usage
• Rules
  • Class and Member design
  • Interface design
  • Function design
    • Anonymous functions
    • Async functions
  • Variable design
  • Requires and Imports
  • Types
  • Objects
  • Strings
  • Operators
  • Conditional statements
  • for statement
  • switch statement
  • try statement
  • Maintainability
  • Layout
    • Curly braces
    • Whitespace
    • Empty lines
    • Alignment
  • Naming
    • Classes and Interfaces
    • Variables and Functions
  • Documentation
    • Inline Comments
    • JSDoc Comments
  • Misc
  • Codelyzer rules
• Contributing
• License

Getting started

Installation

You can install zift-tslint using npm

npm install zift-tslint --save

Note: You should have already installed [TSLint] and [codelyzer].

Usage

To use these [TSLint] rules, use configuration inheritance via the extends keyword.

A sample configuration is shown below, where tslint.json lives adjacent to your node_modules folder:

{
  "rulesDirectory": [
    "node_modules/codelyzer"
  ],
  "extends": ["zift-tslint"]
}

Rules

Class and Member design

• Do not use classes unless required.

"no-unnecessary-class": [
  true,
  "allow-constructor-only",
  "allow-static-only",
  "allow-empty-class"
]

• Do not specify the public keyword (this is the default accessibility level).
• private and private static members in classes should be denoted with the private keyword.

"member-access": [
  true,
  "no-public"
]

• Member ordering should be in the following way:
  • Public members should be ordered before private members.
  • Static members should be ordered before instance members.
  • Variables should be ordered before functions.

"member-ordering": [
  true,
  "public-before-private",
  "static-before-instance",
  "variables-before-functions"
]

• Member overloads should be consecutive.

"adjacent-overload-signatures": true

• Always prefer unifying any two overloads into one, by using a union or an optional/rest parameter.

"unified-signatures": true

• Always prefer functions over private members that do not use this.

"prefer-function-over-method": [
  true,
  "allow-public",
  "allow-protected"
]

• Do not use the this keyword outside class context (including functions in methods).

"no-invalid-this": [
  true
]

• Do not invoke the super method twice in a constructor (except in branched statements or nested class constructors).

"no-duplicate-super": true

• Always prefer parentheses () when invoking a constructor via the new keyword.

"new-parens": true

• Do not define new for classes.

"no-misused-new": true

• Do not use the constructors of String, Number, and Boolean.

"no-construct": true

Interface design

• Do not define constructors for interfaces.

See: Class and Member design

• Do not use empty interfaces.

"no-empty-interface": true

• Always prefer foo(): void over foo: () => void in interfaces and types.

"prefer-method-signature": true

• Always prefer an interface declaration over a type literal (type T = { ... }).

"interface-over-type-literal": true

Function design

• Functions should be defined right after the variable declarations.

See: Class and Member design

• Do not invoke arguments.callee within a function, as it makes impossible various performance optimizations.

"no-arg": true

• fat-arrow/lambda functions should have parenthesis () around the function parameters (except if removing them is allowed by TypeScript).

"arrow-parens": [
  true,
  "ban-single-arg-parens"
]

• Always prefer () => x over () => { return x; }.

"arrow-return-shorthand": true

Async functions

• Do not use the unnecessary return await.

"no-return-await": true

Variable design

• Always prefer const keyword where appropriate, for values that should never change.
• Then prefer let everywhere else.
• Do not use the var keyword.

"prefer-const": true

• Do not use implied global variables.
• Do not define a variable on the global scope from within a smaller scope.

"no-shadowed-variable": [
  true,
  {
    "temporalDeadZone": false
  }
],

• Declare one variable at a time (except in loops).

"one-variable-per-declaration": [
  true,
  "ignore-for-loop"
]

• Do not use duplicate variable names in the same block scope.

"no-duplicate-variable": [
  true,
  "check-parameters"
]

• Do not use a var/let statement or destructuring initializer to be initialized to undefined.

"no-unnecessary-initializer": true

Requires and Imports

• Do not import modules that are not listed as a dependency in the project's package.json.

"no-implicit-dependencies": true

• Always use the import statement keywords in alphabetical order.

"ordered-imports": [
  true,
  {
    "named-imports-order": "case-insensitive",
    "grouped-imports": true
  }
]

• Always use a single import statement per module.

"no-duplicate-imports": true

• Always import submodules from rxjs.

"import-blacklist": [
  true,
  "rxjs"
]

• Do not use require statements at all (use ES6-style import statement instead).

"no-require-imports": true

• Do not use default exports in ES6-style modules.

"no-default-export": true

• Do not use /// <reference path=> imports statements at all (use ES6-style import statement instead).

"no-reference": true

Types

• Always prefer defining the return type of functions, methods and property declarations explicitly.
• Types should be used whenever necessary (no implicit any).

"typedef": [
  true,
  "call-signature",
  "property-declaration"
]

• Always prefer type inference over explicit type declaration (except for function return types).

"no-inferrable-types": true

• Always prefer the use of as Type for type assertions over <Type>.

"no-angle-bracket-type-assertion": true

• Always prefer writing an interface or literal type with just a call signature as a function type.

"callable-types": true

• Do not use the null keyword, always return undefined instead of a null reference.

"no-null-keyword": true

• Do not use non-null assertions.

"no-non-null-assertion": true

Objects

• Always prefer ES6 object spread operator whenever possible.

"prefer-object-spread": true

• Always prefer ES6 object literal shorthand whenever possible.

"object-literal-shorthand": true

• Always prefer object property names using literals whenever possible.

"object-literal-key-quotes": [
  true,
  "as-needed"
]

Strings

• Always prefer single-quotes '' for all strings, and use double-quotes "" for strings within strings.

"quotemark": [
  true,
  "single",
  "avoid-template",
  "avoid-escape"
]

• Always prefer template expressions over string literal concatenation.

"prefer-template": true

• Do not use string templates outside template strings (``).

"no-invalid-template-strings": true

Operators

• Always prefer using === and !== operators whenever possible.

== and != operators do type coercion, which can lead to headaches when debugging code.

"triple-equals": [
  true,
  "allow-null-check"
]

• In a binary expression, a literal should always be on the right-hand side.

"binary-expression-operand-order": true

• Do not use the delete operator with dynamic key expressions.

"no-dynamic-delete": true

• Do not use bitwise operators.

"no-bitwise": true

• Always prefer using isNan function to check NaN references.

"use-isnan": true

• Assignment expressions inside of the condition block of if, while, and do while statements should be avoided.

"no-conditional-assignment": true

Conditional statements

• Always prefer conditional expression over a standard if statement.

"prefer-conditional-expression": [
  true,
  "check-else-if"
]

for statement

• Always prefer for-of loop over a standard for loop.

"prefer-for-of": true

• Filter for-in statements with an if statement (this prevents accidental iteration over properties inherited from an object???s prototype).

"forin": true

switch statement

• Each switch statement should have a default case.

"switch-default": true

• Each switch case except default should end with break, return, or throw.

"no-switch-case-fall-through": true

• Do not use duplicate switch cases.

"no-duplicate-switch-case": true

try statement

• Do not use control flow statements, such as return, continue, break and throws in finally blocks.

"no-unsafe-finally": true

Maintainability

• Use UTF-8 encoding.

"encoding": true

• Limit the level of complexity (cyclomatic complexity) in a function/method by 20 branches.

"cyclomatic-complexity": [
  true,
  20
]

• Files should not exceed 1500 lines of code.

"max-file-line-count": [true, 1500]

• Keep the length of each line under 140 characters.

"max-line-length": [
  true,
  140
]

• Use 2 spaces for indentation.

"indent": [
  true,
  "spaces",
  4
]

• All files should end in a new line.

"eofline": true

Layout

Curly braces

Use curly braces as needed.

"curly": [
  true,
  "as-needed"
]

Whitespace

Whitespaces should be used in the following circumstances:

• All branching statements (if/else/for/while) should be followed by one space.
• Variable declarations should be separated by one space around the type specification and equals token.
• There should be one space between the typecast and its target.
• All operators except the period ., left parenthesis (, and left bracket [ should be separated from their operands by one space.
• There should be no space between the unary/incremental operators !x, -x, +x, ~x, ++x, --x and its operand.
• There should be one space between the type operators |, & and its operand.
• There should be one space after the left curly brace { and before the right curly brace } containing import statement keywords.
• Each separator (,,;) in the control part of a for statement should be followed with one space.
• There should be no space after the rest/spread operator ....
• The left curly brace { followed by a right parenthesis ) should always separated by one space.

"whitespace": [
  true,
  "check-branch",
  "check-decl",
  "check-operator",
  "check-module",
  "check-separator",
  "check-rest-spread",
  "check-type",
  "check-typecast",
  "check-type-operator",
  "check-preblock"
]

• For each call signature, index signature, parameter, property declaration and variable declaration;
  • There should be no space between the parameter and the colon : indicating the type declaration.
  • There should be one space between the colon : and the type declaration.

"typedef-whitespace": [
  true,
  {
    "call-signature": "nospace",
    "index-signature": "nospace",
    "parameter": "nospace",
    "property-declaration": "nospace",
    "variable-declaration": "nospace"
  },
  {
    "call-signature": "onespace",
    "index-signature": "onespace",
    "parameter": "onespace",
    "property-declaration": "onespace",
    "variable-declaration": "onespace"
  }
]

• For each function, class member and constructor;
  • There should be no space between the name of the function/member and the left parenthesis ( of its parameter list.
• For each fat-arrow/lambda function;
  • There should be one space between the right parenthesis ) and the =>.

"space-before-function-paren": [
  true,
  {
    "anonymous": "never",
    "named": "never",
    "asyncArrow": "always",
    "method": "never",
    "constructor": "never"
  }
]

• There should be no space within parenthesis.

"space-within-parens": 0

• Put one space between the import statement keywords.

"import-spacing": true

• Do not use trailing whitespaces at the end of a line

"no-trailing-whitespace": true

Empty lines

Empty lines improve code readability by allowing the developer to logically group code blocks.

• There should be an empty line before the return statement.

"newline-before-return": true

• There should be a separate line for each chained method call.

"newline-per-chained-call": true

• For each function, anonymous function, class member, constructor, else, catch and finally statements;
  • There should be one space between the right parenthesis ) and the left curly { brace that begins the statement body.
• For each fat-arrow/lambda function;
  • There should be one space between the => and the left curly brace { that begins the statement body.
• else statements should indented to align with the line containing the closing brace for the if statement.
• catch and finally statements should indented to align with the line containing the closing brace for the try statement.

"one-line": [
  true,
  "check-open-brace",
  "check-whitespace",
  "check-else",
  "check-catch",
  "check-finally"
]

• Do not use more than one empty line in a row.

"no-consecutive-blank-lines": [
  true,
  1
]

Alignment

• A semicolon should be placed at the end of every simple statement (except at the end of bound class methods).

"semicolon": [
  true,
  "always",
  "strict-bound-class-methods"
]

• Vertically align parameters and statements (helps maintain a readable, consistent style in your codebase).

"align": [
  true,
  "parameters",
  "statements"
]

• Do not use trailing commas in array and object literals, destructuring assignments, function typings, named imports/exports and function parameters.

"trailing-comma": [
  true,
  {
    "multiline": "never",
    "singleline": "never",
    "esSpecCompliant": true
  }
]

Naming

Classes and Interfaces

• Class and interface names should be in PascalCase.

"class-name": true

Variables and Functions

• All variable, and function names should be in camelCase.
• Do not use trailing underscore _ characters.

"variable-name": [
  true,
  "check-format",
  "allow-leading-underscore",
  "ban-keywords"
]

Documentation

Inline Comments

• Always prefer // for all inline comments.
• There should be one space before the comment.

"comment-format": [
  true,
  "check-space"
]

JSDoc Comments

• [JSDoc] comments should start with /** and end with */.

"jsdoc-format": [
  true,
  "check-multiline-start"
]

• Do not use redundant [JSDoc] comments.

"no-redundant-jsdoc": true

Misc

• Do not use the console method (such messages are considered to be for debugging purposes and therefore might ship to the production environment).

"no-console": [
  true,
  "log",
  "debug",
  "info",
  "time",
  "timeEnd",
  "trace"
]

• Do not use the debugger statement (this might cause the environment to stop execution and start up a debugger, if not omitted on the production code).

"no-debugger": true

• Do not use the eval function (using eval on untrusted code might open a program up to several different injection attacks).

"no-eval": true

• Do not throw plain strings or concatenations of strings (because only Errors produce proper stack traces).

"no-string-throw": true

• Do not use namespaces (using namespace {} is outdated).

"no-namespace": true

• Do not use internal modules (using module {} is outdated).

"no-internal-module": true

• Always prefer the radix parameter to be specified when calling parseInt.

"radix": true

• Do not leave unused expressions in the code.

"no-unused-expression": [
  true,
  "allow-fast-null-checks"
],

• Do not use empty blocks {} in the code.

"no-empty": true

• Do not use missing elements in arrays.

"no-sparse-arrays": true

Codelyzer rules

"angular-whitespace": [
  true,
  "check-interpolation",
  "check-semicolon"
],
"banana-in-box": true,
"templates-no-negated-async": true,
"directive-selector": [
  true,
  "attribute",
  [
    "ngx",
    "test"
  ],
  "camelCase"
],
"use-input-property-decorator": true,
"use-output-property-decorator": true,
"use-host-property-decorator": true,
"use-view-encapsulation": true,
"no-attribute-parameter-decorator": true,
"no-output-named-after-standard-event": true,
"no-input-rename": true,
"no-output-rename": true,
"no-output-on-prefix": true,
"no-forward-ref": true,
"no-unused-css": true,
"use-life-cycle-interface": true,
"contextual-life-cycle": true,
"trackBy-function": true,
"use-pipe-transform-interface": true,
"component-class-suffix": [
  true,
  "Component"
],
"directive-class-suffix": [
  true,
  "Directive"
],
"pipe-impure": false,
"i18n": [
  true,
  "check-id",
  "check-text"
]

Copyright ZiftSolution (c) 2018