Rule Description KPI URL
import-spacing Ensures proper spacing between import statement keywords Understandability https://palantir.github.io/tslint/rules/max-classes-per-file
interface-name Makes it easy to differentiate interfaces from regular classes at a glance. Understandability https://palantir.github.io/tslint/rules/max-file-line-count
indent Using only one of tabs or spaces for indentation leads to more consistent editor behavior, cleaner diffs in version control, and easier programmatic manipulation. Understandability https://palantir.github.io/tslint/rules/file-header
max-line-length Limiting the length of a line of code improves code readability. It also makes comparing code side-by-side easier and improves compatibility with various editors, IDEs, and diff viewers. Maintainability https://palantir.github.io/tslint/rules/no-parameter-reassignment
arrow-parens Maintains stylistic consistency with other arrow function definitions. Understandability https://palantir.github.io/tslint/rules/no-eval
no-use-before-declare This rule is primarily useful when using the var keyword since the compiler will automatically detect if a block-scoped let and const variable is used before declaration. Since most modern TypeScript doesn’t use var, this rule is generally discouraged and is kept around for legacy purposes. It is slow to compute, is not enabled in the built-in configuration presets, and should not be used to inform TSLint design decisions. Robustness https://palantir.github.io/tslint/rules/radix
newline-before-return Helps maintain a readable style in your codebase. Understandability https://palantir.github.io/tslint/rules/switch-default
prefer-conditional-expression This reduces duplication and can eliminate an unnecessary variable declaration. Efficiency https://palantir.github.io/tslint/rules/no-angle-bracket-type-assertion
new-parens Maintains stylistic consistency with other function calls. Understandability https://palantir.github.io/tslint/rules/object-literal-shorthand
align Helps maintain a readable, consistent style in your codebase. Understandability https://palantir.github.io/tslint/rules/no-unbound-method
space-before-function-paren Require or disallow a space before function parenthesis Understandability https://palantir.github.io/tslint/rules/callable-types
space-within-parens Enforces spaces within parentheses or disallow them. Empty parentheses () are always allowed. Understandability https://palantir.github.io/tslint/rules/deprecation
one-variable-per-declaration Disallows multiple variable definitions in the same declaration statement. Understandability https://palantir.github.io/tslint/rules/no-reference
typedef-whitespace Determines if a space is required or not before the colon in a type specifier. Understandability https://palantir.github.io/tslint/rules/strict-type-predicates
semicolon Enforces consistent semicolon usage at the end of every statement. Understandability https://palantir.github.io/tslint/rules/import-spacing
trailing-comma Requires or disallows trailing commas in array and object literals, destructuring assignments, function typings, named imports and exports and function parameters. Understandability https://palantir.github.io/tslint/rules/indent
no-consecutive-blank-lines Helps maintain a readable style in your codebase. Understandability https://palantir.github.io/tslint/rules/typedef-whitespace
prefer-function-over-method Warns for class methods that do not use “this”. Accuracy https://palantir.github.io/tslint/rules/eofline
no-boolean-literal-compare Warns on comparison to a boolean literal, as in x === true. Robustness https://palantir.github.io/tslint/rules/type-literal-delimiter
completed-docs Enforces documentation for important items be filled out. Understandability https://palantir.github.io/tslint/rules/jsdoc-format
linebreak-style Enforces a consistent linebreak style. Understandability https://palantir.github.io/tslint/rules/one-line
no-default-export Named imports/exports promote clarity. In addition, current tooling differs on the correct way to handle default imports/exports. Avoiding them all together can help avoid tooling bugs and conflicts. Understandability https://palantir.github.io/tslint/rules/number-literal-format
no-trailing-whitespace Keeps version control diffs clean as it prevents accidental whitespace from being committed. Understandability
eofline It is a standard convention to end files with a newline. Understandability
whitespace Helps maintain a readable, consistent style in your codebase. Understandability
no-irregular-whitespace Disallow irregular whitespace within a file, including strings and comments. Understandability
ordered-imports Requires that import statements be alphabetized and grouped. Enforce a consistent ordering for ES6 imports: Named imports must be alphabetized (i.e. import {A, B, C} from foo;) The exact ordering can be controlled by the named-imports-order option. “longName as name” imports are ordered by ‘longName’. Import sources must be alphabetized within groups, i.e.: import * as foo from “a” ; import * as bar from “b” ; Groups of imports are delineated by blank lines. You can use these to group imports however you like, e.g. by first- vs. third-party or thematically or can you can enforce a grouping of third-party, parent directories and the current directory. Understandability
type-literal-delimiter Checks that type literal members are separated by semicolons. Enforces a trailing semicolon for multiline type literals. Understandability
jsdoc-format Helps maintain a consistent, readable style for JSDoc comments. Understandability
one-line Requires the specified tokens to be on the same line as the expression preceding them. Understandability
no-duplicate-imports Using a single import statement per module will make the code clearer because you can see everything being imported from that module on one line. Understandability https://palantir.github.io/tslint/rules/no-console
member-ordering A consistent ordering for class members can make classes easier to read, navigate, and edit. Maintainability https://palantir.github.io/tslint/rules/no-magic-numbers
strict-boolean-expressions Restricts the types allowed in boolean expressions. By default only booleans are allowed. The following nodes are checked: Arguments to the !, &&, and || operators The condition in a conditional expression (cond ? x : y) Conditions for if, for, while, and do-while statements. Understandability https://palantir.github.io/tslint/rules/no-var-keyword
number-literal-format Checks that decimal literals should begin with ‘0.’ instead of just ‘.’, and should not end with a trailing ‘0’. Understandability https://palantir.github.io/tslint/rules/arrow-return-shorthand/
no-empty Empty blocks are often indicators of missing code. Accuracy https://palantir.github.io/tslint/rules/no-submodule-imports
object-literal-sort-keys Useful in preventing merge conflicts Maintainability https://palantir.github.io/tslint/rules/no-shadowed-variable
comment-format Helps maintain a consistent, readable style in your codebase. Understandability https://palantir.github.io/tslint/rules/variable-name
missing-jsdoc All files must have a top level JSDoc comment. A JSDoc comment starts with /** (not one more or one less asterisk) and a JSDoc at the ‘top-level’ appears without leading spaces. Trailing spaces are acceptable but not recommended. Understandability https://palantir.github.io/tslint/rules/no-null-keyword
missing-optional-annotation Deprecated – This rule is now enforced by the TypeScript compiler. A parameter that follows one or more parameters marked as optional is not itself marked optional Understandability https://palantir.github.io/tslint/rules/no-namespace
mocha-avoid-only Do not invoke Mocha’s describe.only, it.only or context.only functions. These functions are useful ways to run a single unit test or a single test case during your build, but please be careful to not push these methods calls to your version control repositiory because it will turn off any of the other tests. Testability https://palantir.github.io/tslint/rules/prefer-template
mocha-unneeded-done A function declares a MochaDone parameter but only resolves it synchronously in the main function. The MochaDone parameter can be safely removed from the parameter list. Maintainability https://palantir.github.io/tslint/rules/no-construct
no-constant-condition Do not use constant expressions in conditions. Similar to the ESLint no-constant-conditionrule. Since version 2.0.14, this rule accepts a parameter called checkLoops which defaults to true. If set to false then loops are not checked for conditionals. For example, disable loop checking with [ true, { ‘checkLoops’: false } ] Maintainability https://palantir.github.io/tslint/rules/import-blacklist
no-control-regex Do not use control characters in regular expressions . Similar to the ESLint no-control-regex rule Maintainability https://palantir.github.io/tslint/rules/no-bitwise
no-cookies Do not use cookies Maintainability https://palantir.github.io/tslint/rules/prefer-object-spread
no-delete-expression Do not delete expressions. Only properties should be deleted Maintainability https://palantir.github.io/tslint/rules/restrict-plus-operands
no-document-write Do not use document.write. A serious problems: document.write does not work in XHTML. document.write does not directly modify the DOM, preventing further manipulation. document.write executed after the page has finished loading will overwrite the page, or write a new page, or not work. document.write executes where encountered: it cannot inject at a given node point. document.write is effectively writing serialised text which is not the way the DOM works conceptually, and is an easy way to create bugs (.innerHTML has the same problem) Maintainability https://palantir.github.io/tslint/rules/newline-per-chained-call
no-empty-line-after-opening-brace Avoid an empty line after an opening brace. Maintainability https://palantir.github.io/tslint/rules/no-unused-expression
no-for-in Avoid use of for-in statements. They can be replaced by Object.keys Maintainability https://palantir.github.io/tslint/rules/no-empty-interface
no-function-constructor-with-string-args Do not use the version of the Function constructor that accepts a string argument to define the body of the function. Maintainability https://palantir.github.io/tslint/rules/only-arrow-functions
no-function-expression Do not use function expressions; use arrow functions (lambdas) instead. In general, lambdas are simpler to use and avoid the confusion about what the ‘this’ references points to. Function expressions that contain a ‘this’ reference are allowed and will not create a failure. Understandability https://palantir.github.io/tslint/rules/no-require-imports
no-increment-decrement Avoid use of increment and decrement operators particularly as part of complicated expressions Maintainability https://palantir.github.io/tslint/rules/no-void-expression
no-jquery-raw-elements Do not create HTML elements using JQuery and string concatenation. It is error prone and can hide subtle defects. Instead use the JQuery element API. Resource Utilization
no-multiline-string Do not declare multiline strings. Maintainability
no-single-line-block-comment Avoid single line block comments and use single line comments instead. Block comments do not nest properly and have no advantages over normal single-line comments Understandability
no-string-based-set-immediate Do not use the version of setImmediate that accepts code as a string argument. However, it is acceptable to use the version of setImmediate where a direct reference to a function is provided as the callback argument Maintainability
no-string-based-set-interval Do not use the version of setInterval that accepts code as a string argument. However, it is acceptable to use the version of setInterval where a direct reference to a function is provided as the callback argument Maintainability https://msdn.microsoft.com/en-us/library/cc307418.aspx
no-string-based-set-timeout Do not use the version of setTimeout that accepts code as a string argument. However, it is acceptable to use the version of setTimeout where a direct reference to a function is provided as the callback argument Maintainability
no-unexternalized-strings Ensures that double quoted strings are passed to a localize call to provide proper strings for different locales. The rule can be configured using an object literal as document in the feature request Maintainability
no-unnecessary-local-variable Do not declare a variable only to return it from the function on the next line. It is always less code to simply return the expression that initializes the variable. Resource Utilization
no-unnecessary-semicolons Remove unnecessary semicolons Maintainability
prefer-type-cast Prefer the tradition type casts instead of the new ‘as-cast’ syntax. For example, prefer myVariable instead of myVariable as string. Rule ignores any file ending in .tsx. If you prefer the opposite and want to see the as type casts, then enable the tslint rule named ‘no-angle-bracket-type-assertion’ Accuracy
react-a11y-anchors For accessibility of your website, anchor element link text should be at least 4 characters long. Links with the same HREF should have the same link text. Links that point to different HREFs should have different link text. Links with images and text content, the alt attribute should be unique to the text content or empty. An an anchor element’s href prop value must not be just #.
References: WCAG Rule 38: Link text should be as least four 4 characters long WCAG Rule 39: Links with the same HREF should have the same link text WCAG Rule 41: Links that point to different HREFs should have different link text WCAG Rule 43: Links with images and text content, the alt attribute should be unique to the text content or empty		 Understandability
react-tsx-curly-spacing Consistently use spaces around the brace characters of JSX attributes. You can either allow or ban spaces between the braces and the values they enclose.  One of the two following options are required: * “always” enforces a space inside of curly braces (default) * “never” disallows spaces inside of curly braces By default, braces spanning multiple lines are not allowed with either setting. If you want to allow them you can specify an additional allowMultiline property with the value false. Examples:  * “react-tsx-curly-spacing”: [true, “always”] * “react-tsx-curly-spacing”: [true, “never”] * “react-tsx-curly-spacing”: [true, “never”, {“allowMultiline”: false}] References * eslint-plugin-react jsx-curly-spacing rule  * tslint-react jsx-curly-spacing rule Maintainability https://github.com/Microsoft/tslint-microsoft-contrib/wiki/react-no-dangerous-html-Rule
react-unused-props-and-state Remove unneeded properties defined in React Props and State interfaces. Any interface named Props or State is defined as a React interface. All fields in these interfaces must be referenced. This rule can be configured with regexes to match custom Props and State interface names.  Example for including all interfaces ending with Props or State:  [ true, { ‘props-interface-regex’: ‘Props$’, ‘state-interface-regex’: ‘State$’ } ] Resource Utilization
await-promise While it is valid TypeScript to await a non-Promise-like value (it will resolve immediately), this pattern is often a programmer error and the resulting semantics can be unintuitive. Maintainability https://palantir.github.io/tslint/rules/no-unsafe-any
strict-type-predicates Warns for type predicates that are always true or always false. Works for ‘typeof’ comparisons to constants (e.g. ‘typeof foo === “string”’), and equality comparison to ‘null’/’undefined’. (TypeScript won’t let you compare ‘1 === 2’, but it has an exception for ‘1 === undefined’.) Does not yet work for ‘instanceof’. Does not warn for ‘if (x.y)’ where ‘x.y’ is always truthy. For that, see strict-boolean-expressions. This rule requires strictNullChecks to work properly. Maintainability https://palantir.github.io/tslint/rules/no-this-assignment