Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
Closed
Description
I'd like to have a rule that enforces some strict conventions on identifier names.camelcase also allows PascalCase and withid-match it's impossible to enforce this:
// Validconstfoo=getString();// InvalidconstFoo=getString();// Invalid, also conflicts with new-capconstfoo=createClass();// function createClass(): new (...args: any[]) => any// Invalidconstfoo:React.FC= ...;// Any name is [in]valid?constfoo=Math.random()<0.5 ?createClass() :createString();
It also was a limitation for tslint, so there are few relevant issues:
- Can't use Pascal case when declaring a stateless functional component (SFC) palantir/tslint-react#120
- naming-convention: constructorVariable ajafff/tslint-consistent-codestyle#49
- naming-conventions: question - recognize if variable is primitive ajafff/tslint-consistent-codestyle#125
I'm not really sure what kind of configuration fits this rule (or multiple rules?). For me it would be enough to have a stricter version of camelcase that keeps all classes and functions returningJSX.Element
in PascalCase and everything else in camelCase, but for some more complex cases it may be worth to have extensible configuration, similar tonaming-convention from tslint-consistent-codestyle, which also would cover#515.