Removing ableist language in code is important; it helps to create and maintain an environment that welcomes all developers of all backgrounds, while emphasizing that we as developers select the most articulate, precise, descriptive language we can rather than relying on metaphors. Quite simply, avoiding ableist language lets us make sure we are inclusive of all developers, while moving toward language that is simultaneously more acccessible to developers whose first language might not be our own.
The phrase sanity check is ableist, and unnecessarily references mental health in our code bases. It denotes that people with mental illnesses are inferior, wrong, or incorrect, and the phrase sanity continues to be used by employers and other individuals to discriminate against these people.
There are a ton of alternatives, and one of the best ways to select one is to ask yourself: What am I actually checking? and select something more descriptive. In everyday conversation, we can simply drop the idiom completely and say something akin to Let's check to ensure everything is working.
If this doesn't help, consider one of these many alternatives. I'm prone to using the first two in my own code, though these are gleaned from many developers:
- Quick check
- Initial check
- Confidence check
- Coherence check
- Soundness check
- Calibration check
- Rationality check
One to avoid? Health check. Along with again tieing in discussions of health and disability, this phrase already carries a lot of previous implications from other products that may obfuscate what you're actually trying to say.
very late to the party, but still relevant 4 years later.
my suggestions in order of preference:
we can combine happy with the other three, creating:
combining any of main, basic, and core with each other might make sense, but I couldn't think of a useful combination.
IMO, sanity check is a very loaded term that can have very different meanings for different people, teams, and companies, and that is only considering the professional interpretation, rather than the mental health interpretation. as such, I think we can be more accurate and use other terms that better define our goals in testing. the terms I suggested can express slightly different things and can even be used together to describe intentions more accurately.
in the context of math, a sanity check is a basic test to quickly evaluate whether a claim or the result of a calculation can possibly be true.
in the context of programming, a sanity check is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected, which is a slightly different meaning.
to the best of my knowledge, sanity testing roughly means testing the happy path of the basic functionality. it is more comprehensive than smoke testing and less comprehensive than other types of testing.
so the general escalation of the testing suites is as such:
sanity testshappy testing: see you can use it correctly.also, if we want to contrast happy to express tests that check incorrect usage, we might use sad, but shouldn't really because happy stems from happy path, and sad path is not a generally used term in the industry, so perhaps we can use faulty? but that's out of bound for this discussion. maybe next time.
that's all from me. I truly wish this highly important topic will get the attention it deserves. let's talk about it some more!