Skip to content
This repository was archived by the owner on Aug 31, 2023. It is now read-only.

Add inconsiderateLanguage lint rule#267

Merged
sebmck merged 1 commit into
masterfrom
problematic-terms
Apr 13, 2020
Merged

Add inconsiderateLanguage lint rule#267
sebmck merged 1 commit into
masterfrom
problematic-terms

Conversation

@sebmck

@sebmck sebmck commented Apr 13, 2020

Copy link
Copy Markdown
Contributor

This PR adds a new lint rule called inconsiderateLanguage. It produces errors for specific phrases such as blacklist and whitelist, and suggests alternatives like denylist and allowlist. Right now these are the only two terms we have definitions for. The description was taken from retext-equality.

Some interesting implementation details:

  • Check comments and identifiers. I was uncertain about what identifiers to check. Maybe you're using an API that only allows "blacklist" so I was considering omitting object properties. But that doesn't make much sense when we have comment suppressions. So better to be overly broad, since so far we encourage the liberal usage of suppression comments.
  • Does not check strings. Maybe it should?
  • Implements an autofix.
  • Suggestions preserve original casing.
  • Diagnostics point to the exact location in the source rather than the whole identifier or comment.

Diagnostics output:

 unknown:1 lint/inconsiderateLanguage FIXABLE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Replace racially-charged language with more accurate and inclusive words

    BLACKLIST;
    ^^^^^^^^^ 

  ℹ Instead of BLACKLIST use DENYLIST

 unknown:1:4 lint/inconsiderateLanguage FIXABLE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Replace racially-charged language with more accurate and inclusive words

    someBlacklist;
        ^^^^^^^^^ 

  ℹ Instead of Blacklist use Denylist

 unknown:1 lint/inconsiderateLanguage FIXABLE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Replace racially-charged language with more accurate and inclusive words

    blacklist;
    ^^^^^^^^^ 

  ℹ Instead of blacklist use denylist

@jamiebuilds

Copy link
Copy Markdown
Contributor

Q: Where do comment suppressions go for comments? I don't think I've ever encountered a lint error in a comment before

@sebmck

sebmck commented Apr 13, 2020

Copy link
Copy Markdown
Contributor Author

Before the comment:

// rome-suppress-next-line lint/inconsiderateLanguage
// blacklist

@sebmck sebmck merged commit 3945c3d into master Apr 13, 2020
@sebmck sebmck deleted the problematic-terms branch April 13, 2020 23:52
@sticker221

Copy link
Copy Markdown

Do the origins of these two terms really have anything to do with race or are they commonly used with a racist connotation though?

@sebmck

sebmck commented Apr 14, 2020

Copy link
Copy Markdown
Contributor Author

It's black and white dualism which assumes that white = good and black = evil. There isn't really a good justification for using it, even in non racial contexts, when the alternative, allow and deny, are much clearer, to both English and non-English speakers,.

@sticker221

Copy link
Copy Markdown

These words can have legitimate bad connotations in certain situations though, e.g. black may allude to darkness (danger) and white to light (safety). Colors are used metaphorically differently throughout many languages really. There are many words we could change to reflect better their meaning, but thats not a good enough reason to rule them off our vocab

@sticker221

Copy link
Copy Markdown

Btw the University of Indiana has a list of acceptable metaphorical uses of colors in english and korean link. I understand the good intentions, but I dislike changing our language when nobody's being hurt.

@diokey

diokey commented Apr 14, 2020

Copy link
Copy Markdown
Contributor

Well, it's just a lint rule. People can disable it if they have a legitimate use case but this forces them to be intentional about it.

@lcdproductions

Copy link
Copy Markdown

It's comical that one would even take 5min to put this rule in place...what a great joke.

@sebmck

sebmck commented Apr 14, 2020

Copy link
Copy Markdown
Contributor Author

Using this rule is literally zero effort. There’s an autofix so you don’t even need to update the code yourself and it’s easy to suppress if you really want it. The benefit far outweighs the cost here. I’m locking this PR because there’s nothing to debate here.

@rome rome locked and limited conversation to collaborators Apr 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants