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
Do we really need Naming/InclusiveLanguage
enabled by default?
#9895
Comments
Found real very simple code example: This line in gemspec raise a hit
|
I agree that it might be too much for some cases. I was always concern about checking strings by default. Btw, the cop's configuration is super flexible - one can easily limit this only to identifiers for instance. Anyways, I'm definitely considering disabling the cop by default. |
… `FlaggedTerms` for `Naming/InclusiveLanguage` Fixes rubocop#9895 and follow up rubocop#9893 (comment). This PR sets `CheckStrings: false` and removes `master` from `FlaggedTerms` for `Naming/InclusiveLanguage` because it has an unexpectedly impact for many users who give feedback.
…edTerms` for `Naming/InclusiveLanguage` Fixes #9895 and follow up #9893 (comment). This PR sets `CheckStrings: false` and removes `master` from `FlaggedTerms` for `Naming/InclusiveLanguage` because it has an unexpectedly impact for many users who give feedback.
We've cut a new release with a more permissive configuration for the cop. It shouldn't be noisy for anyone at this point. |
@bbatsov Thanks for very fast reaction |
I think this cop should be disable by default, because there is a lot of github repos that still using
master
as default branch and any code that works with those repo will be flaggedActual behavior
RuboCop version
The text was updated successfully, but these errors were encountered: