SharePoint Framework coding best practice rules

These specific modules should not be imported

Description	Severity	Area of Impact	Impact	Action	Additional Reference
Overloaded functions should be defined consecutively	LOW	Scalability	Having overloaded functions at different locations in a class can be confusing.	Reorder the members in the class so that overloaded functions are defined consecutively.	https://palantir.github.io/tslint/rules/adjacent-overload-signatures/
Code should be vertically aligned	LOW	Manageability	Consistent alignment for code statements helps keep code readable and clear. Statements misaligned from the standard can be harder to read and understand.	Re-align the code	https://palantir.github.io/tslint/rules/align/
T[]or "Array" should be used to define arrays.	HIGH	Scalability	Not using these operators loses type safety	Use "T[]" or "Array" to define arrays.	https://palantir.github.io/tslint/rules/array-type/
Parenthesis should be used around the parameters of arrow function definitions.	HIGH	Manageability	Maintains stylistic consistency with other arrow function definitions.	Add parenthesis around the parameters of arrow function definitions.'	https://palantir.github.io/tslint/rules/arrow-parens/
The shortened version of return should be used in arrow functions	LOW	Manageability	It's unnecessary to include return and {} brackets in arrow lambdas. Leaving them out results in simpler and easier to read code.	Use () => x instead of () => { return x;}	https://palantir.github.io/tslint/rules/arrow-return-shorthand/
Should not use 'await' of a non-Promise value and 'for-await-of' of a non-AsyncIterable value.	HIGH	Scalability	While it is valid JavaScript 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.	Ensure that only Promise-like values are waited for	https://palantir.github.io/tslint/rules/await-promise/
These specific functions or global methods should not be used.	HIGH	Security	Certain functions or global methods can be disallowed by this rule as they are considered unsafe (such as eval)	Replace use of disallowed functions	'https://palantir.github.io/tslint/rules/ban/'
The comma operator should not be used	HIGH	Manageability	Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.	Avoid using the comma operator	'https://palantir.github.io/tslint/rules/ban-comma-operator/'
'"// @ts-ignore comments should not be used'	HIGH	Manageability	Use of ts-ignore suppresses compilation warnings, and can hide issues in the code.	Remove all usages of ts-ignore comments. Address warnings appropriately.	'https://palantir.github.io/tslint/rules/ban-ts-ignore/'
General types representing boxed primitives should not be used	HIGH	Manageability	Non-primitive boxed objects are almost never used appropriately in JavaScript code.	Use the primitive types instead.	'https://palantir.github.io/tslint/rules/ban-types/'
"Yoda" expressions should be avoided	LOW	Manageability	Expressions like 1 + x are sometimes referred to as "Yoda" expressions because they read opposite to how we would normally speak the expression. Sticking to a consistent grammar for conditions helps keep code readable and understandable.	Place literals on the right-hand side of expressions if possible.	'https://palantir.github.io/tslint/rules/binary-expression-operand-order/'
Interfaces or literal types with only a call signature should be expressed as function types	LOW	Scalability	An interface or literal type with just a call signature can be written as a function type.	Change the implementation to a function type	'https://palantir.github.io/tslint/rules/callable-types/'
Class and Interface names should use PascalCase	MEDIUM	Manageability	JavaScript and general programming convention is to refer to classes in PascalCase. It's confusing to use camelCase or other conventions for class names.	Ensure that Classes and Interfaces are named with PascalCase	'https://palantir.github.io/tslint/rules/class-name/'
Single line comments should be consistently formatted	LOW	Scalability	Helps maintain a consistent, readable style in your codebase.	Ensure that single line comments follow a consistent format	'https://palantir.github.io/tslint/rules/comment-format/'
Only a limited set of comment types should be used	LOW	Scalability	Helps maintain a consistent, readable style in your codebase.	Ensure that only a limited set of comment types are used	'https://palantir.github.io/tslint/rules/comment-type/'
Important items should have JSDoc comments	MEDIUM	Manageability	Important components should be documented.	Ensure that important items include JSDoc comments	'https://palantir.github.io/tslint/rules/completed-docs/'
For loop statements should use braces	HIGH	Manageability	'ot including braces in loop statements may cause unexpected bugs	Include braces in all loop statements	'https://palantir.github.io/tslint/rules/curly/'
Cyclomatic complexity should not be too high	HIGH	Manageability	Cyclomatic complexity is a code metric which indicates the level of complexity in a function. High cyclomatic complexity indicates confusing code which may be prone to errors or difficult to modify.	Refactor to simple functions with self-descriptive names	'https://palantir.github.io/tslint/rules/cyclomatic-complexity/'
Deprecated APIs should not be used	HIGH	Security	Using deprecated APIs is a Security risk	Upgrade to using supported versions	'https://palantir.github.io/tslint/rules/deprecation/'
UTF-8 file encoding should be used	MEDIUM	Scalability	Using different encodings can cause issues with code merges, etc.	Ensure that code is consistently UTF-8 encoded	'https://palantir.github.io/tslint/rules/encoding/'
Files should end with en-of-line	LOW	Manageability	'It is a standard convention to end files with a newline.'	Add a newline character to the end of each file	'https://palantir.github.io/tslint/rules/eofline/'
A consistent file header should be used	MEDIUM	Scalability	Using a consistent file header can provide important information across your code base	Ensure that a consistent header is used	'https://palantir.github.io/tslint/rules/file-header/'
A consistent file naming convention should be used	MEDIUM	Scalability	Maintaining a consistent style across a file hierarchy makes the code easier to navigate	Ensure that a consistent file naming convention is used	'https://palantir.github.io/tslint/rules/file-name-casing/'
for (... in ...) statements should be filtered with an if statement	HIGH	Scalability	Using for (... in ...) statements without a filtering if statement can accidental iteration over properties inherited from an object's prototype.	Consider using a Map or Set if you are storing collections of objects. Using Objects can cause occasional edge case bugs, such as if a key is named hasOwnProperty	'https://palantir.github.io/tslint/rules/forin/'
Function constructors should not be used	HIGH	Security	Calling the constructor directly is similar to eval, which is a symptom of design issues. String inputs don't receive type checking and can cause Performance issues, particularly when dynamically created.	If you need to dynamically create functions, use factory functions that themselves return functions.	'https://palantir.github.io/tslint/rules/function-constructor/'
Forbidden modules should not be imported	HIGH	Security	For some libraries, importing the library directly can cause unused submodules to be loaded, so you may want to block these imports and require that users directly import only the submodules they need. In other cases, you may simply want to ban an import because using it is undesirable or unsafe.	Validate why a forbidden module was attempted to be imported.	'https://palantir.github.io/tslint/rules/import-blacklist/'
Import statement keywords should be properly spaced	LOW	Manageability	Proper spacing aids readability	Use at least one whitespace between import statement keywords	'https://palantir.github.io/tslint/rules/import-spacing/'
The explicit += and -= operators should be used	MEDIUM	Scalability	It's easy to type +i or ~~i instead of --~~i or ++i, and won't always result in invalid code.	Ensure that the operators += and -= are used instead of ++i, --i	'https://palantir.github.io/tslint/rules/increment-decrement/'
Spaces should be used instead of tabs	LOW	Manageability	Using only one of tabs or spaces for indentation leads to more consistent editor behavior, cleaner diffs in version control, and easier programmatic manipulation.	Replace tabs with four spaces	'https://palantir.github.io/tslint/rules/indent/'
Interface names should begin with I	LOW	Scalability	Makes it easy to differentiate interfaces from regular classes at a glance.	Ensure that all interface names begin with "I"	'https://palantir.github.io/tslint/rules/interface-name/'
Interfaces should be used instead of type literals	MEDIUM	Scalability	Interfaces are generally preferred over type literals because interfaces can be implemented, extended and merged.	Replace type literals with interfaces	'https://palantir.github.io/tslint/rules/interface-over-type-literal/'
JSDoc comments should be follow proper standards	MEDIUM	Manageability	Helps maintain a consistent, readable style for JSDoc comments.	Use standards for JSDoc comments	'https://palantir.github.io/tslint/rules/jsdoc-format/'
Labels should only be used for flow loop control	MEDIUM	Manageability	Labels in JavaScript only can be used in conjunction with break or continue, constructs meant to be used for loop flow control. While you can theoretically use labels on any block statement in JS, it is considered poor code structure to do so.	Use labels only in the context of loop flow control.	'https://palantir.github.io/tslint/rules/label-position/'
A consistent line break character should be used	MEDIUM	Manageability	All files should use the same linebreak character	Ensure that all files use the same line break character	'https://palantir.github.io/tslint/rules/linebreak-style/'
A default import should have the same name as the declaration it imports	MEDIUM	Scalability	This aids readability of the code	Ensure that a default import has the same name as the declaration it imports.	'https://palantir.github.io/tslint/rules/match-default-export-name/'
A file should only contain one class	MEDIUM	Scalability	Files should have a single responsibility so that that classes each exist in their own files	Refactor to ensure that each class is defined in its own file	'https://palantir.github.io/tslint/rules/max-classes-per-file/'
Files should not exceed a set number of lines	HIGH	Scalability	Excessively long files indicate that a class is taking on too many responsibilities	Refactor to more modular classes	'https://palantir.github.io/tslint/rules/max-file-line-count/'
Lines should have a maximum length	LOW	Manageability	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.'	Ensure that lines do not exceed the maximum allowed size	'https://palantir.github.io/tslint/rules/max-line-length/'
Class members should have explicit visibility declarations	MEDIUM	Scalability	Explicit visibility declarations can make code more readable . Also, because TypeScript's default visibility is public, members lacking a visibility declaration may be an indication of an accidental leak of class internals.	Explicitly include member visibility declarations, even if they are "public".	'https://palantir.github.io/tslint/rules/member-access/'
Class structure should be consistent	LOW	Manageability	A consistent ordering for class members can make classes easier to read, navigate, and edit.	Ensure that all your classes follow the same structure.	'https://palantir.github.io/tslint/rules/member-ordering/'
Parenthesis should be used when invoking a constructor via the new keyword	MEDIUM	Manageability	Maintains stylistic consistency with other function calls.	Use parentheses when invoking a constructor via the new keyword.	'https://palantir.github.io/tslint/rules/new-parens/'
A return statement should be preceded by a blank line	LOW	Manageability	Helps maintain a readable style in your codebase.	Add carriage returns where necessary	'https://palantir.github.io/tslint/rules/newline-before-return/'
Chained method calls should be broken apart onto separate lines	LOW	Manageability	This style helps to keep code 'vertical', avoiding the need for side-scrolling in IDEs or text editors.	Chained method calls should be placed in separate lines.	'https://palantir.github.io/tslint/rules/newline-per-chained-call/'
"as Type" should be used for type assertions instead of "<Type>"	MEDIUM	Scalability	Both formats of type assertions have the same effect, but only as type assertions work in .tsx files.	Ensure that "as Type" is consistently used	'https://palantir.github.io/tslint/rules/no-angle-bracket-type-assertion/'
"Any" should not be used as a type declaration	HIGH	Scalability	Using any as a type declaration nullifies the compile-time benefits of the type system.	If you are dealing with data of unknown or any types, you should not be accessing members of it. Either add type annotations for properties that may exist or change the data type to the empty object type {}.Alternately, if you are creating storage or handling for consistent but unknown types, such as in data structures or serialization, use <T> template types for generic type handling.	'https://palantir.github.io/tslint/rules/no-any/'
"arguments.callee" should not be used	MEDIUM	Performance	Using arguments.callee makes various Performance optimizations impossible.	Do not use arguments.callee	'https://palantir.github.io/tslint/rules/no-arg/'
Bitwise operators should not be used	HIGH	Manageability	Bitwise operators are often typos - for example bool1 & bool2 instead of bool1 && bool2. They also can be an indicator of overly clever code which decreases maintainability.	Do not use bitwise operators	'https://palantir.github.io/tslint/rules/no-bitwise/'
Comparing boolean values to boolean literals should be avoided	LOW	Manageability	Comparing boolean values to boolean literals is unnecessary, as those expressions will result in booleans too. Just use the boolean values directly or negate them.	Avoid comparing boolean values to boolean literals	'https://palantir.github.io/tslint/rules/no-boolean-literal-compare/'
Assignments in conditionals should not be used	HIGH	Manageability	Assignments in conditionals are often typos: for example if (var1 = var2) instead of if (var1 == var2). They also can be an indicator of overly clever code which decreases maintainability.	Do not use assignments in conditionals	'https://palantir.github.io/tslint/rules/no-conditional-assignment/'
More than one consecutive blank line should be avoided	LOW	Manageability	Extra blank lines take up extra space and add little to a semantic understanding of the code. It can be harder to read through files when fewer components can fit into the screen. If you find a file is so large you feel a need to split them up with extra blank lines or comments, consider splitting your file into smaller files.	Remove unnecessary blank lines.	'https://palantir.github.io/tslint/rules/no-consecutive-blank-lines/'
Console methods should not be used	HIGH	Security	Console methods are not appropriate for production code.	Do not use console methods.	'https://palantir.github.io/tslint/rules/no-console/'
String, Number, and Boolean constructors should not be used	MEDIUM	Scalability	There is little reason to use String, Number, or Boolean as constructors. In almost all cases, the regular function-call version is more appropriate.	Use the regular function-call version	'https://palantir.github.io/tslint/rules/no-construct/'
Debugger statements should not be used	HIGH	Security	Debugger statements aren't appropriate for production code.	Remove debugger statements	'https://palantir.github.io/tslint/rules/no-debugger/'
Default exports should be avoided in ES6-style modules	MEDIUM	Scalability	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.	Use named exports instead	'https://palantir.github.io/tslint/rules/no-default-export/'
Importing default members from ES6-style modules should be avoided	MEDIUM	Scalability	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.	Replace default with named imports	'https://palantir.github.io/tslint/rules/no-default-import/'
Multiple import statements from the same module should not be used	LOW	Scalability	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.	Use a single import statement per module	'https://palantir.github.io/tslint/rules/no-duplicate-imports/'
'Super should only be called once in constructors'	HIGH	Scalability	The second call to 'super()' will fail at runtime.	Remove any extra calls to super()	'https://palantir.github.io/tslint/rules/no-duplicate-super/'
Switch statements should not contain duplicate cases	LOW	Manageability	Duplicate cases in switch statements are always a mistake	Remove the duplicate cases	'https://palantir.github.io/tslint/rules/no-duplicate-switch-case/'
Duplicate variables should not be defined in the same block scope	HIGH	Manageability	duplicate variable declarations in the same block scope will cause problems at runtime. This is only possible when using the var keyword - the compiler will detect re-declarations of let and const variables.	Remove duplicate variables	'https://palantir.github.io/tslint/rules/no-duplicate-variable/'
The delete operator should not be used with computed key expressions	HIGH	Manageability	Deleting dynamically computed keys is dangerous and not well optimized.	Consider using a Map or Set if you are storing collections of objects. Using Objects can cause occasional edge case bugs, such as if a key is named hasOwnProperty	'https://palantir.github.io/tslint/rules/no-dynamic-delete/'
Empty blocks should not be used	LOW	Scalability	Empty blocks are often indicators of missing code.	Remove, or complete, empty blocks	'https://palantir.github.io/tslint/rules/no-empty/'
Empty interfaces (interfaces declaring no members) should not be used	HIGH	Scalability	An empty interface is equivalent to its supertype (or {}). Therefore it is unnecessary and can be confusing.	Remove the empty interface or add methods to it.	'https://palantir.github.io/tslint/rules/no-empty-interface/'
The eval() function should not be used	HIGH	Security	eval() is dangerous as it allows arbitrary code execution with full privileges'	Remove all uses of the eval function	'https://palantir.github.io/tslint/rules/no-eval/'
'Unhandled promises should not be used'	MEDIUM	Scalability	'Unhandled Promises can cause unexpected behavior, such as resolving at unexpected times.	Return Promises from functions that start them, then handle them in calling code	'https://palantir.github.io/tslint/rules/no-floating-promises/'
Arrays should not be iterated with a for - in loop	MEDIUM	Scalability	A for-in loop (for (var k in o)) iterates over the properties of an Object. While it is legal to use for-in loops with array types, it is not common. for-in will iterate over the indices of the array as strings, omitting any holes in the array.	Use a for-of loop instead	'https://palantir.github.io/tslint/rules/no-for-in-array/'
Modules which are not listed as dependency in the project's package.json should not be imported	HIGH	Security	Uncontrolled module imports can be a Security risk	Ensure that only controlled modules are imported	'https://palantir.github.io/tslint/rules/no-implicit-dependencies/'
Imports with explicit side-effects should not be used	MEDIUM	Scalability	Imports with side effects may have behavior which is hard for static verification.	Avoid import statements with side-effect	'https://palantir.github.io/tslint/rules/no-import-side-effect/'
Trivially inferred types should not be used	LOW	Scalability	Explicitly declaring the type of a variable which is initialized adds unneeded verbosity.	Remove the type declaration	'https://palantir.github.io/tslint/rules/no-inferrable-types/'
Type inference of {} (empty object type) at function and constructor call sites should not be used	MEDIUM	Manageability	Prior to TypeScript 3.4, generic type parameters for functions and constructors are inferred as {} (the empty object type) by default when no type parameter is explicitly supplied or when the compiler cannot infer a more specific type. This is often undesirable as the call is meant to be of a more specific type.	Use specific type parameters	'https://palantir.github.io/tslint/rules/no-inferred-empty-object-type/'
The internal 'module' syntax should not be used	MEDIUM	Scalability	Using module leads to a confusion of concepts with external modules.	Use the newer namespace keyword instead	'https://palantir.github.io/tslint/rules/no-internal-module/'
The sequence "${" should not be used in non-template strings	LOW	Scalability	Interpolation will only work for template strings.	Use "${" only in template strings	'https://palantir.github.io/tslint/rules/no-invalid-template-strings/'
The "this" keyword should not be used outside classes	MEDIUM	Manageability	This outside of a class in code that is using ES6-class syntax is almost always a mistake.	Remove usages of this outside classes	'https://palantir.github.io/tslint/rules/no-invalid-this/'
Irregular whitespace should be avoided	LOW	Manageability	'Irregular whitespace hurts readability'	Use of whitespace should be consistent	'https://palantir.github.io/tslint/rules/no-irregular-whitespace/'
Magic numbers should not be used	HIGH	Manageability	Magic numbers should be avoided as they often lack documentation.	Use a named constant to provide implicit documentation via the variable name	'https://palantir.github.io/tslint/rules/no-magic-numbers/'
Mergeable namespaces should not be used in the same file	MEDIUM	Scalability	Splitting the declaration of namespace members in a single file can cause confusion	Group all namespace members in a single declaration	'https://palantir.github.io/tslint/rules/no-mergeable-namespace/'
The "new" keyword should not be used to define constructors for interfaces	MEDIUM	Scalability	Interfaces in TypeScript aren't meant to describe constructors on their implementations. The new descriptor is primarily for describing JavaScript libraries.	If you are trying to describe a function known to be a class, it is typically better to declare class	'https://palantir.github.io/tslint/rules/no-misused-new/'
Module and Namespace should not be used	MEDIUM	Scalability	ES6-style external modules are the standard way to modularize code. Using module {} and namespace {} are outdated ways to organize TypeScript code.	Use the ES6 style for declaring external modules	'https://palantir.github.io/tslint/rules/no-namespace/'
The non null assertion should not be used	HIGH	Scalability	Using non-null assertion cancels the benefits of the strict null checking mode.	Ensure that the type system is aware that an instance is required to not be null	'https://palantir.github.io/tslint/rules/no-non-null-assertion/'
The "null" keyword literal should not be used	MEDIUM	Manageability	JavaScript originally intended undefined to refer to a value that doesn't yet exist, while null was meant to refer to a value that does exist but points to nothing. That's confusing.	Use "undefined". "undefined" is the default value when object members don't exist, and is the return value for newer native collection APIs such as Map.get when collection values don't exist	'https://palantir.github.io/tslint/rules/no-null-keyword/'
Object literals should not appear in type assertion expressions	HIGH	Manageability	Always prefer const x: T = { ... }; to const x = { ... } as T; . The type assertion in the latter case is either unnecessary or hides an error.	Use const x: T = { ... }	'https://palantir.github.io/tslint/rules/no-object-literal-type-assertion/'
Parameter properties should not be used in class constructors	HIGH	Manageability	Parameter properties can be confusing to those new to TS as they are less explicit than other ways of declaring and initializing class members.	Keep member variable declarations in one list directly above the class constructor (instead of mixed between direct class members and constructor parameter properties)	'https://palantir.github.io/tslint/rules/no-parameter-properties/'
Function parameters should not be reassigned inside the function	HIGH	Manageability	Changing the value of incoming parameters to a function is confusing and can cause hard to debug issues.	Avoid reassigning parameters	'https://palantir.github.io/tslint/rules/no-parameter-reassignment/'
JSDoc which duplicates TypeScript functionality should not be used	LOW	Manageability	It is redundant to add JSDoc which describes the intent of functionality provided by TypeScript	Remove the redundant JSDoc	'https://palantir.github.io/tslint/rules/no-redundant-jsdoc/'
<reference> should not be used to load other files	MEDIUM	Scalability	Using /// <reference path=> comments to load other files is outdated.	Use ES6-style imports to reference other files	'https://palantir.github.io/tslint/rules/no-reference/'
References to imported types should not be used	LOW	Manageability	It is redundant to use <reference types="foo" /> if you already "import foo"	Remove the redundant reference	'https://palantir.github.io/tslint/rules/no-reference-import/'
The `require()` function should be avoided	LOW	Manageability	Prefer the newer ES6-style imports over require().	Refactor to use imports	'https://palantir.github.io/tslint/rules/no-require-imports/'
"Event", "name" and "length" should not be used as global variables	LOW	Manageability	Disallowing usage of specific global variables can be useful if you want to allow a set of global variables by enabling an environment, but still want to disallow some of those.	Use different global variable names	'https://palantir.github.io/tslint/rules/no-restricted-globals/'
'Unnecessary "return await" calls should not be used'	MEDIUM	Scalability	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.	Remove these unnecessary calls	'https://palantir.github.io/tslint/rules/no-return-await/'
Shadowing variable declarations should not be used	MEDIUM	Scalability	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.	Rename the shadowing variables	'https://palantir.github.io/tslint/rules/no-shadowed-variable/'
Arrays should not be defined with empty elements	LOW	Scalability	Missing elements are probably an accidentally duplicated comma.	Ensure duplicated commas in array definitions are removed	'https://palantir.github.io/tslint/rules/no-sparse-arrays/'
Unnecessary string literal property access should not be used	LOW	Scalability	If --noImplicitAny is turned off, property access via a string literal will be "any" if the property does not exist.	Use obj.property instead of obj["property"]	'https://palantir.github.io/tslint/rules/no-string-literal/'
Throwing plain strings should be avoided	MEDIUM	Scalability	Only Error objects contain a .stack member equivalent to the current stack trace. Primitives such as strings do not.	Throw an Error with the String message	'https://palantir.github.io/tslint/rules/no-string-throw/'
Submodule imports should not be used	HIGH	Scalability	Submodules of some packages are treated as private APIs and the import paths may change without deprecation periods. It's best to stick with top-level package exports	Remove submodule imports	'https://palantir.github.io/tslint/rules/no-submodule-imports/'
Falling through case statements should be avoided	MEDIUM	Scalability	Fall though in switch statements is often unintentional and a bug.	Remove falling through case statements	'https://palantir.github.io/tslint/rules/no-switch-case-fall-through/'
Unnecessary references to "this" should be avoided	HIGH	Scalability	Assigning a variable to this instead of properly using arrow lambdas may be a symptom of pre-ES6 practices or not managing scope well.	Instead of storing a reference to this and using it inside a function, Use () => arrow lambdas, as they preserve this scope	'https://palantir.github.io/tslint/rules/no-this-assignment/'
Whitespace should be removed from the end of lines	LOW	Manageability	Keeps version control diffs clean as it prevents accidental whitespace from being committed.	Remove trailing whitespace at the end of lines	'https://palantir.github.io/tslint/rules/no-trailing-whitespace/'
Methods should not be used outside method calls	MEDIUM	Scalability	Class functions don't preserve the class scope when passed as standalone variables.	Either use an arrow lambda (() => {...}) or call the function with the correct scope	'https://palantir.github.io/tslint/rules/no-unbound-method/'
Using a callback wrapper on a directly called function should be avoided	LOW	Performance	There's generally no reason to wrap a function with a callback wrapper if it's directly called anyway. Doing so creates extra inline lambdas that slow the runtime down.	Replace x => f(x) with just f	'https://palantir.github.io/tslint/rules/no-unnecessary-callback-wrapper/'
Unnecessary classes should not be defined	MEDIUM	Manageability	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.	Remove unnecessary classes	'https://palantir.github.io/tslint/rules/no-unnecessary-class/'
Var / let statements should not be explicitly initialized to "undefined"	LOW	Scalability	Values in JavaScript default to undefined. There's no need to do so manually.	Remove the unneeded initialization	'https://palantir.github.io/tslint/rules/no-unnecessary-initializer/'
'Unnecessary namespace qualifiers should be avoided'	LOW	Scalability	Unnecessary namespace qualifiers are redundant	Remove the unnecessary namespace qualifiers	'https://palantir.github.io/tslint/rules/no-unnecessary-qualifier/'
Unnecessary type assertion should not be used	LOW	Scalability	Type assertions which do not change the type of the expression are unnecessary	Do not use type assertions when the do not modify the inferred type	'https://palantir.github.io/tslint/rules/no-unnecessary-type-assertion/'
Expressions of type 'any' should not be used in a dynamic way	HIGH	Scalability	If you're dealing with data of unknown or 'any' types, you shouldn't be accessing members of it	'ther add type annotations for properties that may exist or change the data type to the empty object type {}	'https://palantir.github.io/tslint/rules/no-unsafe-any/'
Control flow statements should not be used in finally blocks	LOW	Scalability	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.	Remove control flow statements from finally blocks	'https://palantir.github.io/tslint/rules/no-unsafe-finally/'
Unused expression statements should not be used	LOW	Scalability	Unused expressions are expression statements which are not assignments or function calls (and thus usually no-ops).	Removed any unused expressions	'https://palantir.github.io/tslint/rules/no-unused-expression/'
Unused variables should be avoided	LOW	Manageability	Variables that are declared and not used anywhere in code are likely an error due to incomplete refactoring. Such variables take up space in the code, are mild Performance pains, and can lead to confusion by readers.	Remove any unused variables	'https://palantir.github.io/tslint/rules/no-unused-variable/'
Variables should not be used before their declaration	LOW	Manageability	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.	Do not use variables before declaring them. In fact, do not use "var" at all	'https://palantir.github.io/tslint/rules/no-use-before-declare/'
The "var" keyword should not be used	MEDIUM	Manageability	Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration 'hoisting' (similar to functions) and can appear to be used before declaration.	Use "const" and "let" to define variables instead	'https://palantir.github.io/tslint/rules/no-var-keyword/'
The var keyword should not be used to specify imports	MEDIUM	Scalability	AMD-style require([]) and CommonJS-style require("") statements are environment-specific and more difficult to statically analyse.	Use ES2015-style imports instead. They are part of the JavaScript language specification and recommended as the path going forward. TypeScript will compile them to environment-specific forms as needed	'https://palantir.github.io/tslint/rules/no-var-requires/'
Expressions of type void should appear in statement position	MEDIUM	Manageability	It's misleading returning the results of an expression whose type is void. Attempting to do so is likely a symptom of expecting a different return type from a function.	Do not return expressions of type void	'https://palantir.github.io/tslint/rules/no-void-expression/'
Decimal literals should be consistently formatted	MEDIUM	Manageability	Helps keep a consistent style with numeric literals. Non-standard literals are more difficult to scan through and can be a symptom of typos.	Ensure that all decimal literals have digits to the left of the decimal separator, and do not end in 0	'https://palantir.github.io/tslint/rules/number-literal-format/'
A consistent convention for quoting object literal properties should be used	LOW	Manageability	Object literal property names can be defined in two ways: using literals or using strings. It is a good idea to enforce a consistent style in your code.	Use a standard convention to name object literal property names	'https://palantir.github.io/tslint/rules/object-literal-key-quotes/'
ES6 object literal shorthand should be used	LOW	Manageability	Shorthand object literal syntax is more compact and should be preferred	Use ES6 object literal shorthand	'https://palantir.github.io/tslint/rules/object-literal-shorthand/'
Object literal keys should be sorted	LOW	Scalability	Useful in preventing merge conflicts	Reorder object literal keys alphabetically	'https://palantir.github.io/tslint/rules/object-literal-sort-keys/'
Certain tokens should appear on the same line	LOW	Manageability	For clarity, certain tokens should be on the same line as the expression preceding them.'	Format the code to comply with this rule	'https://palantir.github.io/tslint/rules/one-line/'
Only one variable should be declared on a single line	LOW	Manageability	'For clarity, it is better to declare one variable per line.	Declare one variable per line	'https://palantir.github.io/tslint/rules/one-variable-per-declaration/'
Non-arrow functions should not be used	HIGH	Scalability	Traditional functions don't bind lexical scope, which can lead to unexpected behavior when accessing 'this'.	Use arrow functions instead	'https://palantir.github.io/tslint/rules/only-arrow-functions/'
Import statements should be organized	LOW	Manageability	For clarity, import statements be alphabetized and grouped.	Organize your imports	'https://palantir.github.io/tslint/rules/ordered-imports/'
Conditional expressions should be used to avoid multiple equivalent variable assignments	LOW	Scalability	This reduces duplication and can eliminate an unnecessary variable declaration.	Use a conditional expression instead of assigning to the same thing in each branch of an if statement	'https://palantir.github.io/tslint/rules/prefer-conditional-expression/'
The "const" keyword should be used for constants	MEDIUM	Scalability	If a variable is only assigned to once when it is declared, it should be declared using 'const'	Refactor to use const	'https://palantir.github.io/tslint/rules/prefer-const/'
'for-of' loops should be used in preference to for loops with index	LOW	Manageability	A for-of loop is easier to implement and read when the index is not needed.	Use the for(... of ...) loop syntax	'https://palantir.github.io/tslint/rules/prefer-for-of/'
Functions should be preferred over class methods	MEDIUM	Scalability	Class methods that do not use "this" should be refactored to functions	Refactor methods into functions	'https://palantir.github.io/tslint/rules/prefer-function-over-method/'
The method signature syntax should be used to declare the type of a function	MEDIUM	Manageability	"foo(): void" should be used instead of "foo: () => void" in interfaces and types.	Refactor method signatures	'https://palantir.github.io/tslint/rules/prefer-method-signature/'
"Object.assign()" should not be used	LOW	Scalability	Object spread allows for better type checking and inference.	Ese the ES2018 object spread operator instead of Object.assign()	'https://palantir.github.io/tslint/rules/prefer-object-spread/'
Private variables should be marked as `read-only` if they\'re never modified outside of the constructor	MEDIUM	Scalability	Marking never-modified variables as readonly helps enforce the code's intent of keeping them as never-modified. It can also help prevent accidental changes of members not meant to be changed.	Mark private variables as readonly if they're never modified outside of the constructor	'https://palantir.github.io/tslint/rules/prefer-readonly/'
Switch statements should be used instead of three or more if - === comparisons	MEDIUM	Scalability	'Switch statements are easier to understand than nested if statements'	Refactor to use a switch statement	'https://palantir.github.io/tslint/rules/prefer-switch/'
Template expressions should be used instead of string concatenation	LOW	Performance	Concatenating more than two strings should be done using template expressions	Refactor string concatenations to use template expressions	'https://palantir.github.io/tslint/rules/prefer-template/'
Loops without initializer or incrementor should use "while" instead of "for"	MEDIUM	Manageability	Simplifies the readability of the loop statement, while maintaining the same functionality.	Refactor loops to use while instead of for	'https://palantir.github.io/tslint/rules/prefer-while/'
Functions that return promises should be async	HIGH	Scalability	Non-async Promise-returning functions are technically capable of returning a rejected Promise or throwing an error. This means that consuming code has to handle both cases.	Ensure that Promise-returning functions are always async	'https://palantir.github.io/tslint/rules/promise-function-async/'
String literals should be quoted	MEDIUM	Manageability	String literals should be quoted	Ensure that all string literals are quoted	'https://palantir.github.io/tslint/rules/quotemark/'
"parseInt" should not be called without a radix parameter	MEDIUM	Scalability	Different implementations produce different results when a radix is not specified, usually defaulting the value to 10.	Specify the radix parameter when calling parseInt	'https://palantir.github.io/tslint/rules/radix/'
The "+" operator should only be used when both sides are numbers or strings	MEDIUM	Scalability	When adding two variables, operands must both be of type number or of type string.	Ensure that both sides of the operation are of the same type, number or string	'https://palantir.github.io/tslint/rules/restrict-plus-operands/'
Undefined should be returned instead of null in value-returning functions	LOW	Manageability	Prefer return; in void functions and return undefined; in value-returning functions.	Refactor to return undefined	'https://palantir.github.io/tslint/rules/return-undefined/'
End of statement semicolons should be used consistently	MEDIUM	Manageability	A consistent use of semicolons aids code readability	Ensure that ever statement is terminated with a semicolon	'https://palantir.github.io/tslint/rules/semicolon/'
A whitespace should be included before function parenthesis	LOW	Scalability	A space before function parenthesis aids readability	Insert a space between the function name and the parenthesis	'https://palantir.github.io/tslint/rules/space-before-function-paren/'
'A whitespace should be included after a parenthesis'	LOW	Scalability	A space after a parenthesis aids readability	Add spaces as needed	'https://palantir.github.io/tslint/rules/space-within-parens/'
Only booleans should be used in boolean expressions	MEDIUM	Scalability	Using non-boolean types inside boolean expressions can have unintended effects	Ensure that only boolean types are used in boolean expressions	'https://palantir.github.io/tslint/rules/strict-boolean-expressions/'
Predicates which are always true or false should not be used	MEDIUM	Scalability	An expression which always evaluates to true or false is useless in a predicate	Ensure that expressions in predicates are not always true or false	'https://palantir.github.io/tslint/rules/strict-type-predicates/'
'Switch statements should have a default'	LOW	Scalability	Omitting the default case can cause unexpected behavior at runtime	Ensure that all switch statements have a default case	'https://palantir.github.io/tslint/rules/switch-default/'
The final clause of a switch statement should end in "break"	MEDIUM	Scalability	The final clause of a switch statement should end in break.	Add the break statement	'https://palantir.github.io/tslint/rules/switch-final-break/'
Trailing commas should be used whenever possible	LOW	Manageability	Trailing commas (sometimes called "final commas") can be useful when adding new elements, parameters, or properties to JavaScript code. If you want to add a new property, you can simply add a new line without modifying the previously last line if that line already uses a trailing comma. This makes version-control diffs cleaner and editing code might be less troublesome.	Use trailing commas in array and object literals, destructuring assignments, function typings, named imports and exports and function parameters	'https://palantir.github.io/tslint/rules/trailing-comma/'
The triple equality operator should be used	LOW	Scalability	The behavior of the double equals operator can be unexpected in some cases	Use "===" and "!==" instead of "==" and "!="	'https://palantir.github.io/tslint/rules/triple-equals/'
Type member literals should be separated by semicolon	LOW	Scalability	The semicolon separator aids readability	Use the semicolon separator	'https://palantir.github.io/tslint/rules/type-literal-delimiter/'
Types should be explicitly defined	HIGH	Scalability	Not including explicit types in the code can cause hard to debug issues	Ensure that types are explicitly defined	'https://palantir.github.io/tslint/rules/typedef/'
'Whitespace should be used for type definition'	LOW	Manageability	Adding a whitespace before the colon in a type specifier aids readability.	Ensure that a single whitespace precedes the colon in a type specifier	'https://palantir.github.io/tslint/rules/typedef-whitespace/'
The "typeof" operator should always compare String types	MEDIUM	Scalability	Using undefined types for typeof comparisons may fail at runtime	Ensure that both sides of the typeof comparison are String	'https://palantir.github.io/tslint/rules/typeof-compare/'
Imports should be unified whenever possible	LOW	Scalability	Individual imports add unnecessary verbosity	Unify imports by using a union or an optional/rest parameter	'https://palantir.github.io/tslint/rules/unified-signatures/'
Unnecessary scope binings on functions should be avoided	HIGH	Scalability	Function expressions that are immediately bound to this are equivalent to () =>arrow lambdas. Additionally, there's no use in binding a scope to an arrow lambda, as it already has one.	Remove the unnecessary scope bindings	'https://palantir.github.io/tslint/rules/unnecessary-bind/'
Blank constructors should not be used'	LOW	Manageability	JavaScript implicitly adds a blank constructor when there isn't one. It's not necessary to manually add one in.	Remove any blank constructors	'https://palantir.github.io/tslint/rules/unnecessary-constructor/'
Explicit type declarations on arguments should be avoided if there is a default type	LOW	Scalability	Explicitly specifying the type argument if it is the the default for that type parameter is redundant.	Remove the explicit type declaration for these parameters	'https://palantir.github.io/tslint/rules/use-default-type-parameter/'
The isNaN() function should be used to check for NaN references	HIGH	Scalability	Since NaN !== NaN, comparisons with regular operators will produce unexpected results.	Instead of if (myVar === NaN), do if (isNaN(myVar))	'https://palantir.github.io/tslint/rules/use-isnan/'
Variable naming conventions should be followed	MEDIUM	Scalability	lowerCamelCase should be used for variables, and UPPER_CASE for constants. Typescript keywords should not be used as variable names.	Rename any variables which do not comply with the naming conventions	'https://palantir.github.io/tslint/rules/variable-name/'
Whitespace should be used consistently	LOW	Manageability	A consistent use of whitespace aids readability.	Ensure that whitespace is used consistently	'https://palantir.github.io/tslint/rules/whitespace/'