tslint-consistent-codestyle
tslint-consistent-codestyle copied to clipboard
ajafff
Collection of awesome rules to extend TSLint
Possible options: * `"no-or"` to exempt if statements that have a logical OR in their condition * `"complexity": number` threshold similar to `cyclomatic-complexity`
When extending a class, namingConventionRule should not complain about the names of overridden or implemented abstract methods and accessors.
As requested by @CSchulz, make getter and setter configurable for naming convention. Ideally this could also include type information, so we could force "is" or "has" as prefix for boolean...