Is your rule for a general problem or is it specific to your development style?
General problem of clean coding
What does your suggested rule do?
Basically, avoid people to choose variable name too short that need a comments to explain why it exist.
List several examples where your rule could be used
For example
string d; // elapsed time in days
string s; // elapsed time in second
string e; // error
can be hi-lighted as error if the tslint rule is configure with min-length 3.
This will allow developers to give some thought on the variable name and maybe came with a better variable name that doesn't need a comment:
string elapsedDays
string elapsedSecond
string error
Additional context
I would love to add this rule if you think is a nice add. I also did previously some contribution on codelyzer
Interesting! This could be an option on variable-name rule. What kinds of options would be useful? Anything more complex than minimum number of digits?
We should note that if this is considered useful, there should be exclusions for names that are small by convention, such as in for loops:
```typescript
for (let i = 0; i < something; ++i) { /* .. */ }
It looks a good idea have a withelist of variables name
What are the next steps?
Let's wait a bit to see if the community has feedback on this. It seems like this would be a pretty niche rule that most folks would disable. It's not uncommon to have reasonably named variables of length:
dx/dy/dtage, daySuggestion: how about making this rule in a separate repository & npm package and posting a link to them here? That'll let you work on the rule and experiment with configurations without being tied into the TSLint release process.
yep sounds fine to me I can do it we have in our project a separate rules folder:
https://github.com/Alfresco/alfresco-ng2-components/tree/development/tools/tslint-rules
closing this as it has been built in a separate package. does not belong in main repo anyways as variable names of all lengths can be valid. i, dx, age, ...
@giladgray I just want add that valid !== readable and sometimes readable is more important than valid.
I would like to have it too but for the max length, avoidingToHaveVariablesWrittenLikeThisWhichIThinkIsCrazy.
Also having a min-char set to 3 would exclude cases such like "id", so probably would be nice to have exceptions as well.
Analog usage already existing in ESLint: https://eslint.org/docs/rules/id-length
yep @giladgray as closed a bit too early. I don't know why...
This would be a very useful feature. We want to forbid one-letter arguments in our project, e.g.: handleClick(event) instead of handleClick(e).
Most helpful comment
I would like to have it too but for the max length, avoidingToHaveVariablesWrittenLikeThisWhichIThinkIsCrazy.
Also having a min-char set to 3 would exclude cases such like "id", so probably would be nice to have exceptions as well.
Analog usage already existing in ESLint: https://eslint.org/docs/rules/id-length