Blocklint is a simple command line utility for finding non-inclusive wording with an emphasis on source code. If you’ve used a modern IDE, you know the importance of immediate feedback for compilation errors or even stylistic slip-ups.  Knowing all variables should be declared or that lines must be less than 80 characters long is good, but adhering to those rules takes a back seat when in the flow of writing code.  A linter brings these issues back into your consciousness by highlighting the problematic lines of code.  Over time, the enforced style becomes more intuitive but the linter is always there to nudge you if you slip.

We are in the midst of changing attitudes towards words and phrases that are not inclusive. Not only are developers acknowledging the offensive history of terms like “master/slave” and “blacklist/whitelist”, but we are taking active steps to remove their usage and replace them with more appropriate language.

Alex.js is one option for highlighting offensive language, but it is geared towards text documents such as markdown, misses common constructs in source code, and is also overly broad and prone to false positives.  We have written a linter in python which has a simple goal: find and report usages of words you don’t want in your code.  Blocklint is tested in python 2.7 to 3.8 and works on a wide variety of systems.  You can install it with:

pip install git+https://github.com/PrincetonUniversity/blocklint

Consider the following text file with some non-inclusive words

push to master *
TODO add user to black_list
BlAcKlIsT *
B_Lack_List
B-Lack-List *
B:Lack:List
B.Lack.List
blacklisted
this is aBlacklist
b.la-ck_list
find master/slave *
Add file type to whi_te-list

Alex.js will mark the lines indicated with a *, but notably black_list and aBlacklist are not caught, which are fairly common constructs in source code.  Here is a screenshot of blocklint integrated with vim through ALE (asynchronous lint engine) on some test source code files.

Note that the words are highlighted in comments and treated as exceptions by ALE in all file types.  There are also instructions for setting up pre-commit checks with blocklint and we are receptive to integrating with other editors, just open a new issue to let us know what you use.

Blocklint can accept other word lists to lint against and you can match entire word boundaries or character cases.  As you interact with other libraries you will also notice how entrenched non-inclusive language is in function calls.  Hopefully blocklint is helpful in retraining your fingers from typing master, blacklist and any other words you want to eliminate from your source code.