SharePoint Framework coding best practice rules

These specific modules should not be imported

DescriptionSeverityArea of ImpactImpactActionAdditional Reference
Overloaded functions should be defined consecutivelyLOWScalabilityHaving 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 alignedLOWManageabilityConsistent 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 codehttps://palantir.github.io/tslint/rules/align/
T[]or "Array" should be used to define arrays.HIGHScalabilityNot using these operators loses type safetyUse "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.HIGHManageabilityMaintains 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 functionsLOWManageabilityIt'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.HIGHScalabilityWhile 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 forhttps://palantir.github.io/tslint/rules/await-promise/
These specific functions or global methods should not be used.HIGHSecurityCertain 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 usedHIGHManageabilityUsing 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'HIGHManageabilityUse 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 usedHIGHManageabilityNon-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 avoidedLOWManageabilityExpressions 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 typesLOWScalabilityAn 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 PascalCaseMEDIUMManageabilityJavaScript 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 formattedLOWScalabilityHelps 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 usedLOWScalabilityHelps 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 commentsMEDIUMManageabilityImportant components should be documented.Ensure that important items include JSDoc comments'https://palantir.github.io/tslint/rules/completed-docs/'
For loop statements should use bracesHIGHManageability'ot including braces in loop statements may cause unexpected bugsInclude braces in all loop statements'https://palantir.github.io/tslint/rules/curly/'
Cyclomatic complexity should not be too highHIGHManageabilityCyclomatic 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 usedHIGHSecurityUsing deprecated APIs is a Security riskUpgrade to using supported versions'https://palantir.github.io/tslint/rules/deprecation/'
UTF-8 file encoding should be usedMEDIUMScalabilityUsing 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-lineLOWManageability'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 usedMEDIUMScalabilityUsing a consistent file header can provide important information across your code baseEnsure that a consistent header is used'https://palantir.github.io/tslint/rules/file-header/'
A consistent file naming convention should be usedMEDIUMScalabilityMaintaining a consistent style across a file hierarchy makes the code easier to navigateEnsure 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 statementHIGHScalabilityUsing 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 usedHIGHSecurityCalling 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 importedHIGHSecurityFor 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 spacedLOWManageabilityProper spacing aids readabilityUse at least one whitespace between import statement keywords'https://palantir.github.io/tslint/rules/import-spacing/'
The explicit += and -= operators should be usedMEDIUMScalabilityIt'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 tabsLOWManageabilityUsing 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 ILOWScalabilityMakes 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 literalsMEDIUMScalabilityInterfaces 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 standardsMEDIUMManageabilityHelps 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 controlMEDIUMManageabilityLabels 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 usedMEDIUMManageabilityAll files should use the same linebreak characterEnsure 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 importsMEDIUMScalabilityThis aids readability of the codeEnsure 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 classMEDIUMScalabilityFiles should have a single responsibility so that that classes each exist in their own filesRefactor 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 linesHIGHScalabilityExcessively long files indicate that a class is taking on too many responsibilitiesRefactor to more modular classes'https://palantir.github.io/tslint/rules/max-file-line-count/'
Lines should have a maximum lengthLOWManageabilityLimiting 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 declarationsMEDIUMScalabilityExplicit 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 consistentLOWManageabilityA 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 keywordMEDIUMManageabilityMaintains 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 lineLOWManageabilityHelps 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 linesLOWManageabilityThis 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>"MEDIUMScalabilityBoth 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 declarationHIGHScalabilityUsing 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 usedMEDIUMPerformanceUsing 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 usedHIGHManageabilityBitwise 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 avoidedLOWManageabilityComparing 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 usedHIGHManageabilityAssignments 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 avoidedLOWManageabilityExtra 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 usedHIGHSecurityConsole 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 usedMEDIUMScalabilityThere 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 usedHIGHSecurityDebugger 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 modulesMEDIUMScalabilityNamed 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 avoidedMEDIUMScalabilityNamed 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 usedLOWScalabilityUsing 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'HIGHScalabilityThe 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 casesLOWManageabilityDuplicate cases in switch statements are always a mistakeRemove the duplicate cases'https://palantir.github.io/tslint/rules/no-duplicate-switch-case/'
Duplicate variables should not be defined in the same block scopeHIGHManageabilityduplicate 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 expressionsHIGHManageabilityDeleting 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 usedLOWScalabilityEmpty 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 usedHIGHScalabilityAn 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 usedHIGHSecurityeval() 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'MEDIUMScalability'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 loopMEDIUMScalabilityA 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 importedHIGHSecurityUncontrolled module imports can be a Security riskEnsure that only controlled modules are imported'https://palantir.github.io/tslint/rules/no-implicit-dependencies/'
Imports with explicit side-effects should not be usedMEDIUMScalabilityImports 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 usedLOWScalabilityExplicitly 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 usedMEDIUMManageabilityPrior 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 usedMEDIUMScalabilityUsing 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 stringsLOWScalabilityInterpolation 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 classesMEDIUMManageabilityThis 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 avoidedLOWManageability'Irregular whitespace hurts readability'Use of whitespace should be consistent'https://palantir.github.io/tslint/rules/no-irregular-whitespace/'
Magic numbers should not be usedHIGHManageabilityMagic 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 fileMEDIUMScalabilitySplitting the declaration of namespace members in a single file can cause confusionGroup 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 interfacesMEDIUMScalabilityInterfaces 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 usedMEDIUMScalabilityES6-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 usedHIGHScalabilityUsing 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 usedMEDIUMManageabilityJavaScript 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 expressionsHIGHManageabilityAlways 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 constructorsHIGHManageabilityParameter 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 functionHIGHManageabilityChanging 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 usedLOWManageabilityIt is redundant to add JSDoc which describes the intent of functionality provided by TypeScriptRemove the redundant JSDoc'https://palantir.github.io/tslint/rules/no-redundant-jsdoc/'
<reference> should not be used to load other filesMEDIUMScalabilityUsing /// <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 usedLOWManageabilityIt 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 avoidedLOWManageabilityPrefer 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 variablesLOWManageabilityDisallowing 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'MEDIUMScalabilityAn 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 MEDIUMScalabilityWhen 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 elementsLOWScalabilityMissing 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 usedLOWScalabilityIf --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 avoidedMEDIUMScalabilityOnly 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 usedHIGHScalabilitySubmodules 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 exportsRemove submodule imports'https://palantir.github.io/tslint/rules/no-submodule-imports/'
Falling through case statements should be avoidedMEDIUMScalabilityFall 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 avoidedHIGHScalabilityAssigning 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 linesLOWManageabilityKeeps 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 callsMEDIUMScalabilityClass 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 avoidedLOWPerformanceThere'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 definedMEDIUMManageabilityUsers 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"LOWScalabilityValues 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'LOWScalabilityUnnecessary namespace qualifiers are redundantRemove the unnecessary namespace qualifiers'https://palantir.github.io/tslint/rules/no-unnecessary-qualifier/'
Unnecessary type assertion should not be usedLOWScalabilityType assertions which do not change the type of the expression are unnecessaryDo 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 wayHIGHScalabilityIf 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 blocksLOWScalabilityWhen 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 usedLOWScalabilityUnused 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 avoidedLOWManageabilityVariables 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 declarationLOWManageabilityThis 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 usedMEDIUMManageabilityDeclaring 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 importsMEDIUMScalabilityAMD-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 positionMEDIUMManageabilityIt'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 formattedMEDIUMManageabilityHelps 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 usedLOWManageabilityObject 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 usedLOWManageabilityShorthand object literal syntax is more compact and should be preferredUse ES6 object literal shorthand'https://palantir.github.io/tslint/rules/object-literal-shorthand/'
Object literal keys should be sortedLOWScalabilityUseful in preventing merge conflictsReorder object literal keys alphabetically'https://palantir.github.io/tslint/rules/object-literal-sort-keys/'
Certain tokens should appear on the same lineLOWManageabilityFor 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 lineLOWManageability'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 usedHIGHScalabilityTraditional 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 organizedLOWManageabilityFor 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 assignmentsLOWScalabilityThis 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 constantsMEDIUMScalabilityIf 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 indexLOWManageabilityA 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 methodsMEDIUMScalabilityClass methods that do not use "this" should be refactored to functionsRefactor 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 functionMEDIUMManageability"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 usedLOWScalabilityObject 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 constructorMEDIUMScalabilityMarking 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 - === comparisonsMEDIUMScalability'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 concatenationLOWPerformanceConcatenating more than two strings should be done using template expressionsRefactor 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"MEDIUMManageabilitySimplifies 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 asyncHIGHScalabilityNon-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 quotedMEDIUMManageabilityString literals should be quotedEnsure that all string literals are quoted'https://palantir.github.io/tslint/rules/quotemark/'
"parseInt" should not be called without a radix parameterMEDIUMScalabilityDifferent 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 stringsMEDIUMScalabilityWhen 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 functionsLOWManageabilityPrefer 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 consistentlyMEDIUMManageabilityA consistent use of semicolons aids code readabilityEnsure that ever statement is terminated with a semicolon'https://palantir.github.io/tslint/rules/semicolon/'
A whitespace should be included before function parenthesisLOWScalabilityA space before function parenthesis aids readabilityInsert 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'LOWScalabilityA space after a parenthesis aids readabilityAdd spaces as needed'https://palantir.github.io/tslint/rules/space-within-parens/'
Only booleans should be used in boolean expressionsMEDIUMScalabilityUsing non-boolean types inside boolean expressions can have unintended effectsEnsure 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 usedMEDIUMScalabilityAn expression which always evaluates to true or false is useless in a predicateEnsure 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'LOWScalabilityOmitting the default case can cause unexpected behavior at runtimeEnsure 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"MEDIUMScalabilityThe 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 possibleLOWManageabilityTrailing 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 usedLOWScalabilityThe behavior of the double equals operator can be unexpected in some casesUse "===" and "!==" instead of "==" and "!="'https://palantir.github.io/tslint/rules/triple-equals/'
Type member literals should be separated by semicolonLOWScalabilityThe semicolon separator aids readabilityUse the semicolon separator'https://palantir.github.io/tslint/rules/type-literal-delimiter/'
Types should be explicitly definedHIGHScalabilityNot including explicit types in the code can cause hard to debug issuesEnsure that types are explicitly defined'https://palantir.github.io/tslint/rules/typedef/'
'Whitespace should be used for type definition'LOWManageabilityAdding 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 typesMEDIUMScalabilityUsing undefined types for typeof comparisons may fail at runtimeEnsure that both sides of the typeof comparison are String'https://palantir.github.io/tslint/rules/typeof-compare/'
Imports should be unified whenever possibleLOWScalabilityIndividual imports add unnecessary verbosityUnify 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 avoidedHIGHScalabilityFunction 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'LOWManageabilityJavaScript 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 typeLOWScalabilityExplicitly 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 referencesHIGHScalabilitySince 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 followedMEDIUMScalabilitylowerCamelCase 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 consistentlyLOWManageabilityA consistent use of whitespace aids readability.Ensure that whitespace is used consistently'https://palantir.github.io/tslint/rules/whitespace/'