-
-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reintroduce "length" rules to catch excess #738
Comments
I dunno. I see very little value in this. I don't think I ever got a PR that violated any of these. Sometimes you do need a file with more than 1000 lines. |
Do you really need it or is it inconvenient to split up?
Then True exceptions to this rule have have their own
So it wouldn't affect you and enabling it would take little effort. Linting also affects existing, old, large apps. I think JSX alone can easily be brought to 200 characters, I've seen this in Refined GitHub |
Alright, let's try it then. |
🙌 |
It doesn't make sense to limit lines to 80ch or 120ch, but can we agree that there's zero reason to have a line 1000ch long? Surely there must be a limit?
What if we treat these rules "obvious excess catchers"?
A line-length rule with limit of
1000 characters
wouldn't imply that 999 is fine, but it could still help catch egregiously bad code. True exceptions to this rule have have their owneslint-disable-next-line
Now the issue is what we can agree to be excessive.
try-maximum-statements
sindresorhus/eslint-plugin-unicorn#651Note that xo already has the
complexity
andmax-params
rules enabled, which have a similarly-arbitrary limit on code.XO's "max-*" rules:
https://github.com/xojs/eslint-config-xo/blob/3a5448b349e9cfb6780b476a87bdb96439cea403/index.js#L383-L393
The text was updated successfully, but these errors were encountered: