eslint.md

ESLint Code Checks

UI5 uses ESLint to check JavaScript sources. We agreed to a set of rules which should be enabled for our projects.

In the tables below, each rule is linked to its description and we added some short reasoning for some rules. You can create different rules for your project.

Ruleset

ESLint v1.6.0

Possible Errors

Rule	ESLint recommended	UI5	Comment
comma-dangle	error, "never"	error, "never"
no-cond-assign	error	error
no-console	error	error
no-constant-condition	error	error
no-control-regex	error	error
no-debugger	error	error
no-dupe-args	error	error
no-dupe-keys	error	error
no-duplicate-case	error	error
no-empty-character-class	error	error
no-empty	error	error
no-ex-assign	error	error
no-extra-boolean-cast	error	warning	Too many findings in UI5. Need to be fixed, then we might return to the default setting
no-extra-parens	off	error, "functions"
no-extra-semi	error	error
no-func-assign	error	error
no-inner-declarations	error, "functions"	error, "functions"
no-invalid-regexp	error	error
no-irregular-whitespace	error	error
no-negated-in-lhs	error	error
no-obj-calls	error	error
no-regex-spaces	error	error
no-sparse-arrays	error	error
no-unexpected-multiline	off	TBD (off)
no-unreachable	error	error
use-isnan	error	error
valid-jsdoc	off	warning, "requireReturn": false	Activated as a warning for testing purposes. The results of the current rule implementation have not been satisfying. Our main focus is on @public and @protected documentation. The @private documentation is done more lazily, so we get too many warnings for it (we don’t really care if all parameters of a private method are documented. A comment that describes the intent of the method is sometimes helpful enough). Other aspects that are relevant for us are not checked at all (correct usage of @private @public without additional content for example). That's why we run this rule with level warning only. Maybe we'll contribute or implement our own rule in future.
valid-typeof	error	error

Best practices

Rule	ESLint default	UI5	Comment
accessor-pairs	off	error
block-scoped-var	off	warning	As long as block scope is not really available in Javascript, we think we shouldn't use var declarations that only seem to use it. Therefore we would like to activate this rule with level error, but unfortunately there is a bug in it which complains about variables in switch cases. So it is currently only activated as a warning.
complexity	off	off
consistent-return	off	warning	Some of our methods return a result only under certain circumstances and undefined otherwise. We find it a valid implementation not to return anything or just to write “return;” in the undefined case. But the rule complains about that, so we've reduced its level to warning.
curly	off, "all"	error, "all"
default-case	off	warning	We regard a missing default case as an error, but first wanted to analyze how common this error is in our code. So we configured it as warning only. Might be raised to level error again in future.
dot-notation	off	off	Performance considerations suggest to prefer dot notation for accessing properties (Optimizers / JIT compilers are said to produce faster code for dot access). Nevertheless, there are some cases where we think consistency is worth more than ultimately fast property access. E.g. when some properties in an object are invalid as Javascript names while other names in the same object are. Then the code would be less readable when it used dot access for half of the names while using string access for the others (common example: HTTP headers in the Model layer). We plan to check whether locations with a need for string access are isolated enough to enable the rule for the remainder of our code.
dot-location	off	off
eqeqeq	off	off	We don't run this rule as we like the semantic of the “something == null” check and heavily rely on “==” for string comparison (as we by design support string and String wrappers in parallel). We also haven't been able to give a precise, easy to evaluate specification of when to use "===" and when not. So while enhancing the rule would be nice, it currently is not very likely.
guard-for-in	off	off	From jQuery we inherited the decision not to support scenarios where the Object.prototype has been enhanced with enumerable properties. So we don't activate this rule.
no-alert	off	error
no-caller	off	error
no-div-regex	off	error	A rare edge case of regular expression literals. Relatively easy to avoid and improves readability.
no-else-return	off	off
no-empty-label	off	error
no-eq-null	off	off
no-eval	off	error
no-extend-native	off	error
no-extra-bind	off	error
no-fallthrough	error	error
no-floating-decimal	off	error	Easy to avoid, improves readability.
no-implicit-coercion	off	TBD (off)
no-implied-eval	off	error
no-invalid-this	off	TBD (off)
no-iterator	off	error
no-labels	off	error
no-lone-blocks	off	error
no-loop-func	off	error
no-multi-spaces	off	TBD (off)	~2000 findings
no-multi-str	off	error
no-native-reassign	off	error
no-new-func	off	error
no-new-wrappers	off	warning	In general we agree to this rule but UI5 has features that rely on the use of new String(...). As soon as we have analyzed how isolated the usage of wrappers is, we might enforce this rule again.
no-new	off	warning
no-octal-escape	off	error
no-octal	error	error
no-param-reassign	off	TBD (off)	~1000 findings
no-process-env	off	TBD (off)	0 findings
no-proto	off	error
no-redeclare	error	warning	We really would like to activate this rule but there are still too many findings.
no-return-assign	off	error
no-script-url	off	error
no-self-compare	off	error	Also seemed reasonable to us, but recently there are discussions whether we should allow it for the fast NaN check by x === x.
no-sequences	off	error
no-throw-literal	off	TBD (off)	~25 findings
no-unused-expressions	off	warning	We often use statements like something && something.doSomething() and we like it.
no-useless-call	off	TBD (off)
no-useless-concat	off	TBD (off)
no-void	off	error
no-warning-comments	off	warning	We use TODO markers.
no-with	off	error
radix	off	error	Potential source of errors.
vars-on-top	off	TBD (off)	~10000 findings
wrap-iife	off	error, "any"	Readability is better when wrapping an immediately-invoked function expression (IIFE). As we couldn’t agree on a specific style, we use option "any". Most of our IIFEs use “outside” style.
yoda	off	error

Strict mode

Rule	ESLint default	UI5	Comment
strict	off	error, "function"	We want to avoid the risk when merging strict and non-strict code in a single file – although our current way of merging by design avoids this issue.

Variables

Rule	ESLint default	UI5	Comment
init-declarations	off	TBD (off)
no-catch-shadow	off	error
no-delete-var	error	error
no-label-var	off	error
no-shadow-restricted-names	off	error
no-shadow	off	off
no-undef-init	off	error
no-undef	error	error
no-undefined	off	off
no-unused-vars	error, "vars": "all", "args": "after-used"	error, "vars": "all", "args": "none"	We allow unused function arguments for two reasons: it improves readability when overriding inherited methods and it is common to name all dependencies in the signature of the factory function of an AMD module.
no-use-before-define	off	warning, "nofunc"	Improves readability, but we have too many findings. We explicitly allow out of order function declarations.

Stylistic

Rule	ESLint default	UI5	Comment
array-bracket-spacing	off	TBD (off)
block-spacing	off	TBD (off)
brace-style	off, "1tbs"	error, "1tbs", { "allowSingleLine": true }	For developers that newly join a team this might be an annoying topic, but defining a commonly expected brace-style helps a lot to make the sources look more uniform (which in turn should improve readability).
camelcase	off	warning
comma-spacing	off	TBD (off)	~2000 findings
comma-style	off	TBD (off)
computed-property-spacing	off	TBD (off)
consistent-this	off, "that"	warning, "that"	We like to enforce 'that'. Again, we think it is helpful to standardize on that. Nevertheless, this rule is not without trouble. There are a few cases where naming the substitute with a more appropriate name than "that" can help to understand the code. Therefore we set the rule to warning.
eol-last	off	off
func-names	off	off
func-style	off	off
id-length	off	TBD (off)
id-match	off	TBD (off)
indent	off	TBD (off)	~150000 findings
jsx-quotes	off	off	We don't use JSX.
key-spacing	off	TBD (off)	~15000 findings
lines-around-comment	off	TBD (off)	~10000 findings
linebreak-style	off	error
max-nested-callbacks	off, 2	warning, 3
new-cap	off	warning	In general, we like that rule but there are many places where we access classes in a generic way and then there is a conflict between lower case for variables and upper case for class constructors.
new-parens	off	error
newline-after-var	off	TBD (off)	~7000 findings
no-array-constructor	off	error
no-continue	off	TBD (off)	~100 findings
no-inline-comments	off	TBD (off)	~4000 findings
no-lonely-if	off	warning	We prefer if else if cascades, but there are currently too many findings.
no-mixed-spaces-and-tabs	error	**error, "smart-tabs"
no-multiple-empty-lines	off	TBD (off)	~563 findings
no-nested-ternary	off	error	Again, this rule has been activated to improve code readability - although we would like to support fully parenthesized nested ternaries. But the rule currently doesn’t allow that.
no-negated-condition	off	TBD (off)
no-new-object	off	error
no-restricted-syntax	off	TBD (off)
no-spaced-func	off	error
no-ternary	off	off
no-trailing-spaces	off	off	We wanted to avoid the noise when changing this and there are some places where we would like the rule to accept trailing spaces, e.g. in JSDoc comments.
no-underscore-dangle	off	off	We often (but not always) use a leading underscore for private methods.
no-unneeded-ternary	off	TBD (off)	~50 findings
object-curly-spacing	off	TBD (off)	~1000 findings
one-var	off	off
operator-assignment	off	TBD (off)	~100 findings
operator-linebreak	off	TBD	~400 findings
padded-blocks	off	TBD (off)	~75000 findings
quote-props	off	error, "as-needed", { "keywords": true, "unnecessary": false }	Security Scan Tool requires ES3 syntax.
quotes	off	TBD (off)
require-jsdoc	off	TBD (off)
semi-spacing	off	warning	Set to warning as there are still a few occurrences. We would like to set this to error in future.
semi	off	error
sort-vars	off	off
space-after-keywords	off, "always"	error, "always"	A majority in the team voted for this rule for better readability.
space-before-keywords	off, "always"	off
space-before-blocks	off	TBD (off)	~2000 findings
space-before-function-paren	off	TBD (off)	~10000 findings
space-in-parens	off	TBD (off)	~3000 findings
space-infix-ops	off	error
space-return-throw-case	off	error
space-unary-ops	off, "words": true, "nonwords": false	error, "words": true, "nonwords": false	Again, a majority in the team voted for this rule for better readability.
spaced-comment	off	TBD (off)
wrap-regex	off	off

Technical Ruleset

To apply these rules in other projects, you can use the .eslintrc file from this repository.