Black Lives Matter ruleset

[SSH (Andrew MacCormack)]

• (for any language) Many companies are endeavoring to remove potentially racially-charged terms from their products, including in source code and documentation. Such terms can be offensive or just create unease amongst developers and users of a product. Sonar can help with this, by including rules that detect terms such as “blacklist”, “whitelist”, “slave” and “master” used in code.
• snippet of Noncompliant Code:

def apply_blacklist(x, blacklist, whitelist):
    return [i for i in x if (i in whitelist or i not in blacklist)]
def issue_master_command_to_slave(slave, cmd)
    return os.system(f"ssh {slave} {cmd}")

• snippet of Compilant Code (fixing the above noncompliant code)

def apply_blocklist(x, blocklist, acceptlist):
    return [i for i in x if (i in acceptlist or i not in blocklist)]
def issue_control_command_to_agent(agent, cmd)
    return os.system(f"ssh {agent} {cmd}")

• exceptions to the Noncompliant Code, perhaps a school context, e.g. headmaster

• external references and/or language specifications

  • NCSC
  • Let’s stop saying Master/Slave. Language is a tricky thing. It engages… | by Mike Roberts | Medium
  • Developers renew push to get rid of objectionable code terms to make 'the world a tiny bit more welcoming' • The Register

• type : unsure

[MisterPi]

Seems this should be generalized (see Check identifier spelling against blacklist?) to allow any user-customizable regex-based list. That way:

1. You can check for your own terms, e.g., a misspelling that gets frequently used in an organization;
2. You don’t have to wait for the next SQ release whenever a new word is deemed offensive.

If each regex could have an exception list then that would handle your “headmaster” case. (And that example illustrates the advantage of having a custom list, because I’m sure some people do object to the word “headmaster,” so a canned list won’t please everyone.)