Naming/InclusiveLanguage is politically biased and should not be included by default

[mildred]

Naming/InclusiveLanguage enforces a politically biased view of the world and will drive away legitimate programmers that do not share this specific mindset.

In light of true inclusion for all programmers, this should be disabled by default.

It's one thing to personally refrain from words that one deems inappropriate, it's a completely different thing for an automated tool to forbid every programmer to use the language they naturally speak. it's much more agressive, especially coming from an automated tool that cannot be argued with. Also, not every programmer is a native english speaker, and the deemed inclusive language is not relevant throughout the world.

edit: There a previous issue on this at #9895 but the raised issue was not the same. It only raised the with a repository having a master branch, not on the whole cop.

[joshukraine]

@mildred Absolutely agree.

[Stratus3D]

Agree. Can we get this check disabled by default? If the rubocop project itself has this cop disabled, shouldn't it be disabled by default for everyone?

[daneb]

Please disable this by default!

[bbatsov]

If the rubocop project itself has this cop disabled, shouldn't it be disabled by default for everyone?

Likely an oversight on our part, as the first iteration of the cop wasn't particularly granular in its configuration.

Given how conservative the current defaults are (in essence you'll get only warnings for "blacklist") what exactly is the issue you're facing with the cop? I assume you don't want to update "blacklist" references, but more details would be useful.

[joshukraine]

@bbatsov I’d like to offer some perspective which I hope will be helpful.

Firstly, thank you for all your work on Rubocop. I’ve learned a lot from this tool over the years, and I’m sure we can all agree that Rubocop is an invaluable resource for the Ruby community. 🙂👍🏻

As to the issue at hand, my objection to the Naming/InclusiveLanguage cop is that it represents a departure from the core, stated purpose of Rubocop as a linting/formatting tool. Rubocop has always been (and IMHO should continue to be) concerned with helping Ruby developers improve the technical quality of their code. In contrast to this well-established tradition in the Ruby community, the Naming/InclusiveLanguage cop is attempting to enforce a subjective, opinionated position on a social/political issue. The changes it suggests are not aimed at functional improvements to the code, but rather are based on assumptions about what may or may not offend certain people.

The terms whitelist and blacklist, as examples, have been in use for decades and it is only recently that some groups have begun to assert that these are inherently “racist” or “exclusionary” in some way. This assertion and others like it are neither objective nor widely accepted. They are in fact quite divisive with people on both sides speaking out loudly in defense of their respective views.

But the point here is not that someone’s ideas on issues of term-banning are right or wrong. The point is that Rubcop is not the place to have that conversation. In fact, the word conversation, sadly, is seldom an appropriate term for discussions that involve race and related social issues. Debates about the merit of such terms as “blacklist” are emotionally charged and divisive.

Where does it end? Today we ban “blacklist” and “whitelist”, but what about “whitespace”? What about scientists who publish “white papers” or graduate students who receive “master’s degrees”? Should GitHub begin to ban repos which refuse to rename their master branch to main? Discussions which raise these questions rarely progress very far before the knives come out and people rush to enact bans left and right against anyone and anything that doesn’t conform to their ideology. That doesn’t feel very inclusive to me.

Do we really want to fight this battle in a code formatting tool? If Shopify would like to disallow the use of terms like “blacklist” in their codebase I completely respect their right as a private company to make that decision. A simple find/replace should suffice. But attempting to reach into everyone else’s codebase, enforcing their viewpoint that “blacklist” is not inclusive, is both an overreach and a needless invitation for conflict.

I’ll wrap up with a quote from the Rubocop style guide:

The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Ruby code. They are also meant to reflect real-world usage of Ruby instead of a random ideal. When we had to choose between a very established practice and a subjectively better alternative we’ve opted to recommend the established practice.

Blacklist, whitelist, master branch, et al. are real-world terms in common use by good people of all colors who are not hateful, exclusionary, or racist. If we really want to encourage harmony and good will among software developers, let’s keep social debates in the town halls and HR departments and let Rubocop and its users concern themselves with the technical quality of their Ruby code.

🙂❤️

EDIT: After posting my thoughts above, I discovered that the original author of the ‘Naming/InclusiveLanguage` cop explicitly endorsed disabling it by default. That’s a welcome endorsement and while I stand by my position that Rubocop is not the place to raise these issues, I do appreciate his statement that he “[doesn’t] want to force it or a specific configuration on anyone.” Hopefully that sentiment is something we can all agree on. 🙂

[stevegrossi]

I'm not sure why some believe this particular linter to be "political" (I'm curious what definition of that term you have in mind.) To me it seems straightforwardly a boon to code clarity, which is precisely the purpose for which so many of choose linting tools like Rubocop, an in particular its valuable linters in the Naming namespace. While the whitelist/blacklist distinction has some currency in programming, it is by no means universal. And regardless of one's familiarity with the metaphor, it requires objectively more cognitive overhead to translate the white/black distinction into included/excluded when compared with an alternative like allowlist/blocklist which has the virtue of being true on its face. whitelist/blacklist should be avoided for the same reason we avoid foo and a as variable names: they require programmers to repeatedly waste our limited cognitive processing cycles figuring out what something that is not literally true actually means.

Of course, we all know there are other reasons to avoid making the mental equation of "white" with "allowed" and "black" with "disallowed" a precondition of working in a codebase. Even if you choose to avoid those, the argument for clarity still stands. In both cases, our choice of words has a well-attested effect on what it's like to work in a codebase, and the effectiveness of developers who do.

[johnnyshields]

@stevegrossi

I'm not sure why some believe this particular linter to be "political"

Perhaps because the cop's name is "Naming/InclusiveLanguage", which is direct reference to the political belief that these words "exclude" marginalized groups.

While the whitelist/blacklist distinction has some currency in programming, it is by no means universal

blacklist and whitelist are common words which have been in the English language for 400 years. Unlike foo and a, their meanings are perfectly clear.

Everyone agrees that foo and a are bad (i.e. non-semantic) variable names, but not so for blacklist/whitelist. Hence we should disable the cop, and let people preferentially opt-in.

[stevegrossi]

Perhaps because the cop's name is "Naming/InclusiveLanguage", which is direct reference to the political belief that these words "exclude" marginalized groups.

Hm, but does that not beg the question of what makes matters of exclusionary language a "political belief"? Politics means "relating to the affairs of government," which seems unrelated to the discussion at hand. I mention this only because the OP's primary argument for turning off this linter by default is that it is "politically biased" without defining what that means.

blacklist and whitelist are common words which have been in the English language for 400 years. Unlike foo and a, their meanings are perfectly clear.

You're right that "blacklist" appears to trace back pretty far, which I hadn't realized. I'm always happy for a lesson in etymology, so thanks for prompting that. "whitelist" seems more recent as of the 1800s but far enough back that your point still stands. Though I am sympathetic to @mildred's concern for non-native English speakers and would venture that "allow" and "block" are more intuitive in that case than the figurative usage of black and white for this purpose.

Everyone agrees that foo and a are bad (i.e. non-semantic) variable names, but not so for blacklist/whitelist. Hence we should disable the cop, and let people preferentially opt-in.

This, I think, is the strongest argument against enabling Naming/InclusiveLanguage by default, since it's true to Rubocop's origins as a tool for enforcing Ruby conventions around which there is broad agreement. I'd suggest the conversation here would be best served by focusing on things like that, rather than expanding the definition of politics.

[dvandersluis]

The RuboCop team has decided that we are going to mark this cop as disabled by default, but certainly encourage anyone who benefits from this cop to enable it for your own projects. 🙌