Rule Description KPI URL
no-internal-module Using module leads to a confusion of concepts with external modules. Use the newer namespace keyword instead. Maintainability https://palantir.github.io/tslint/rules/ban-types
no-inferred-empty-object-type Disallow type inference of {} (empty object type) at function and constructor call sites Maintainability https://palantir.github.io/tslint/rules/no-internal-module
no-unsafe-finally When used inside finally blocks, control flow statements, such as return, continue, break and throws override any other control flow statements in the same try/catch scope. This is confusing and unexpected behavior. Maintainability https://palantir.github.io/tslint/rules/no-unsafe-finally
no-mergeable-namespace Disallows mergeable namespaces in the same file. Maintainability https://palantir.github.io/tslint/rules/no-mergeable-namespace
max-classes-per-file Ensures that files have a single responsibility so that that classes each exist in their own files Maintainability https://palantir.github.io/tslint/rules/no-duplicate-variable
max-file-line-count Limiting the number of lines allowed in a file allows files to remain small, single purpose, and maintainable. Maintainability https://palantir.github.io/tslint/rules/triple-equals
no-duplicate-variable A variable can be reassigned if necessary – there’s no good reason to have a duplicate variable declaration. Robustness https://palantir.github.io/tslint/rules/curly
use-isnan NaN !== NaN, comparisons with regular operators will produce unexpected results. So, instead of if (myVar === NaN), do if (isNaN(myVar)). Robustness https://palantir.github.io/tslint/rules/no-duplicate-super
triple-equals Requires === and !== in place of == and !=. Robustness https://palantir.github.io/tslint/rules/no-import-side-effect
file-header Enforces a certain header comment for all files, matched by a regular expression. Maintainability https://palantir.github.io/tslint/rules/ban
no-invalid-template-strings Warns on use of ${ in non-template strings. Maintainability https://palantir.github.io/tslint/rules/no-unnecessary-class
unified-signatures Warns for any two overloads that could be unified into one by using a union or an optional/rest parameter. Maintainability  
no-parameter-reassignment Disallows reassigning parameters. Robustness  
curly 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, he forgot braces and bar++ will be executed no matter what. This rule could prevent such a mistake. Understandability  
no-duplicate-super The second call to “super()” will fail at runtime. Accuracy  
no-eval eval() is dangerous as it allows arbitrary code execution with full privileges. There are alternatives for most of the use cases for eval(). Robustness https://palantir.github.io/tslint/rules/await-promise
radix From MDN: Always specify this parameter to eliminate reader confusion and to guarantee predictable behavior. Different implementations produce different results when a radix is not specified, usually defaulting the value to 10. Maintainability https://palantir.github.io/tslint/rules/interface-name
no-floating-promises Unhandled Promises can cause unexpected behavior, such as resolving at unexpected times. Robustness https://palantir.github.io/tslint/rules/no-use-before-declare
no-object-literal-type-assertion Always prefer const x: T = { … }; to const x = { … } as T;. The type assertion in the latter case is either unnecessary or hides an error. The compiler will warn for excess properties with this syntax, but not missing required fields. For example: const x: { foo: number } = {} will fail to compile, but const x = {} as { foo: number } will succeed. Maintainability https://palantir.github.io/tslint/rules/newline-before-return
no-debugger In general, debugger statements aren’t appropriate for production code. Accuracy https://palantir.github.io/tslint/rules/prefer-conditional-expression
no-unnecessary-initializer Forbids a “var”/”let” statement or destructuring initializer to be initialized to “undefined”. Accuracy https://palantir.github.io/tslint/rules/align
switch-default Require a default case in all switch statements. Robustness https://palantir.github.io/tslint/rules/space-before-function-paren
no-angle-bracket-type-assertion Both formats of type assertions have the same effect, but only as type assertions work in .tsx files. This rule ensures that you have a consistent type assertion style across your codebase. Understandability https://palantir.github.io/tslint/rules/space-within-parens
object-literal-shorthand Enforces/disallows use of ES6 object literal shorthand. Understandability https://palantir.github.io/tslint/rules/no-boolean-literal-compare
adjacent-overload-signatures Improves readability and organization by grouping naturally related items together. Understandability https://palantir.github.io/tslint/rules/no-trailing-whitespace
no-unsafe-any Warns when using an expression of type ‘any’ in a dynamic way. Uses are only allowed if they would work for {} | null | undefined. Type casts and tests are allowed. Expressions that work on all values (such as “” + x) are allowed. Accuracy https://palantir.github.io/tslint/rules/no-irregular-whitespace
no-this-assignment Assigning a variable to this instead of properly using arrow lambdas may be a symptom of pre-ES6 practices or not manging scope well. Accuracy https://palantir.github.io/tslint/rules/no-duplicate-imports
no-unbound-method Warns when a method is used as outside of a method call. Accuracy https://palantir.github.io/tslint/rules/member-ordering
no-return-await An async function always wraps the return value in a Promise. Using return await just adds extra time before the overreaching promise is resolved without changing the semantics. Efficiency  
no-import-side-effect Imports with side effects may have behavior which is hard for static verification. Robustness  
interface-over-type-literal Interfaces are generally preferred over type literals because interfaces can be implemented, extended and merged. Maintainability  
callable-types Style Maintainability https://palantir.github.io/tslint/rules/no-switch-case-fall-through
no-non-null-assertion Using non-null assertion cancels the benefits of the strict null checking mode. Accuracy https://palantir.github.io/tslint/rules/no-arg
deprecation Deprecated APIs should be avoided, and usage updated. Maintainability https://palantir.github.io/tslint/rules/no-string-throw
ban Bans the use of specific functions or global methods. Maintainability https://palantir.github.io/tslint/rules/no-parameter-properties
no-reference Using /// comments to load other files is outdated. Use ES6-style imports to reference other files. Maintainability https://palantir.github.io/tslint/rules/no-sparse-arrays
no-duplicate-switch-case Prevents duplicate cases in switch statements. Accuracy https://palantir.github.io/tslint/rules/no-unnecessary-type-assertion
no-unnecessary-class Users who come from a Java-style OO language may wrap their utility functions in an extra class, instead of putting them at the top level. Maintainability https://palantir.github.io/tslint/rules/binary-expression-operand-order
no-disable-auto-sanitization Do not disable auto-sanitization of HTML because this opens up your page to an XSS attack. Specifically, do not use the execUnsafeLocalFunction or setInnerHTMLUnsafefunctions. Security https://palantir.github.io/tslint/rules/no-invalid-this
no-duplicate-parameter-names This rule is now enforced by the TypeScript compiler. Do not write functions or methods with duplicate parameter names Robustness https://palantir.github.io/tslint/rules/no-dynamic-delete
no-http-string Do not use strings that start with ‘http:’. URL strings should start with ‘https:’. Http strings can be a security problem and indicator that your software may suffer from cookie-stealing attacks. Since version 1.0, this rule takes a list of regular expressions as a parameter. Any string matching that regular expression will be ignored. For example, to allow http connections to example.com and examples.com, configure your rule like this: “no-http-string”: [true, “http://www.example.com/?.*”, “http://www.examples.com/?.*”] Security https://palantir.github.io/tslint/rules/no-unnecessary-callback-wrapper
no-octal-literal Do not use octal literals or escaped octal sequences. Octals in JS have historically been a non-standard extension to the standard (in ES5, which introduces strict mode, they’re in Annex B, which is a collection of non-standard features that most implementations support: except it defines octals in a way incompatible with what websites require), and strict mode made an attempt to disallow all non-standard extensions Maintainability  
no-with-statement Do not use with statements. Assign the item to a new variable instead. Use of the with statement is not recommended, as it may be the source of confusing bugs and compatibility issues. The with statement forces the specified object to be searched first for all name lookups. Therefore all identifiers that aren’t members of the specified object will be found more slowly in a ‘with’ block. Where performance is important, ‘with’ should only be used to encompass code blocks that access members of the specified object. Maintainability  
non-literal-require Detect require() function calls for something that is not a string literal. For security reasons, it is best to only require() string literals. Otherwise, it is perhaps possible for an attacker to somehow change the value and download arbitrary Javascript into your page. Security  
possible-timing-attack Avoid timing attacks by not making direct string comparisons to sensitive data. Do not compare against variables named password, secret, api, apiKey, token, auth, pass, or hash. For more info see Using Node.js Event Loop for Timing Attacks Security