[quality] consider adding more rules to dev.tslint.json

[marcdumais-work]

In PR #353, we introduced a second tslint config file, that extends the one we use for compilation. The new config is used by vscode to highlight broken rules in the editor, encouraging contributors to respect the contained rules, going forward.

Now might be a good opportunity to go crazy and try all the dev rules we think are, on balance, more useful than they are annoying :)

I'll submit a PR with additional rules for dev-tslint.json. I think a good way to go forward is, for as many Theia developers as possible, to temporarily adopt those rules in they daily work, and provide feedback on which rules they dislike, are buggy or are more annoying than useful.

[marcdumais-work]

After discussions in the PR #356, there are valid concerns that we are introducing too many rules, generating too many linter warnings, that would distract from feature development.

An alternate approach is to introduce a third tslint config file that contains all potentially useful rules. That new config file would not be used by vscode by default, but could be for users who want-to. This way it gives the opportunity for contributors to try a wider array of rules and eventually promote the most useful ones to "dev.tslint.json".

[marcdumais-work]

Here's a short list of TSLint rules that I propse we add to dev.tslint.json.

The following rules enforce items defined in Theia's coding guidelines :

enforce having parenthesis around arguments of arrow functions, except if we have a single argument
https://palantir.github.io/tslint/rules/arrow-parens/
"arrow-parens": [
true,
"ban-single-arg-parens"
]

ban use of null keyword literal
https://palantir.github.io/tslint/rules/no-null-keyword/
"no-null-keyword": true

enforce that indentation is exactly 4 spaces
https://palantir.github.io/tslint/rules/indent/
"indent": [true, "spaces", 4]

enforce the proper formatting of JSDoc comments
https://palantir.github.io/tslint/rules/jsdoc-format/
"jsdoc-format": true

enforce using braces for if/for/do/while statements, except for one-liners
https://palantir.github.io/tslint/rules/curly/
"curly": [true, "ignore-same-line"]

only permit declaring a single variable per declaration
https://palantir.github.io/tslint/rules/one-variable-per-declaration/
"one-variable-per-declaration": true

Misc rules:

enforce POSIX standard of ending file with newline char
https://palantir.github.io/tslint/rules/eofline/
"eofline": true

make sure we do not use magic numbers
https://palantir.github.io/tslint/rules/no-magic-numbers/
"no-magic-numbers": true

Since we have a logger, we should probably discourage use of console.log() ,etc...
https://palantir.github.io/tslint/rules/no-console/
"no-console": true

[akosyakov]

Sounds good, let's give it a try.

[marcdumais-work]

#366

[akosyakov]

It would be interesting to play with https://palantir.github.io/tslint/rules/no-inferrable-types/ and https://palantir.github.io/tslint/rules/typedef/. In such way that inferred types are recommended for variables inside method bodies, explicit types are advised for method signatures and for properties anything can be used.

[marcdumais-work]

The following rules we added at the suggesstion of @akosyakov :
Prefer an interface declaration over a type literal (type T = { ... })
https://palantir.github.io/tslint/rules/interface-over-type-literal/
"interface-over-type-literal": true

Suggests to convert () => { return x; } to () => x.
https://palantir.github.io/tslint/rules/arrow-return-shorthand/
"arrow-return-shorthand": [true, "multiline"]

Disallows shadowing variable declarations.
https://palantir.github.io/tslint/rules/no-shadowed-variable/
"no-shadowed-variable": true

Disallows access to the constructors of String, Number, and Boolean.
https://palantir.github.io/tslint/rules/no-construct/
"no-construct": true

Disallows usages of any as a type declaration.
https://palantir.github.io/tslint/rules/no-any/
"no-any": true

[marcdumais-work]

See below for an interesting discussion about the use of "typedef" and "no-inferrable-types" rules together. It seems that no conclusion has been reached yet. One suggestion that looks promising is to deprecate "no-inferrable-types" and add the equivalent as an option of "typedef".

palantir/tslint#711