Have you ever come across a boolean in code (i.e. a TRUE/FALSE) variable and had to stop and question if TRUE meant enabled or disabled? I call this a code smell.
A code smell is a surface indication that usually corresponds to a deeper problem in the system.
https://martinfowler.com/bliki/CodeSmell.html
Table of Contents
Naming variables is hard
One of the hardest things in software engineering is naming variables. They need to be easy to understand, short (ish) yet descriptive. And working in international teams, everyone has a different understanding of language. It’s a nigh impossible task if you ask me.
Kill Switches
Say there’s a kill switch feature that a business or developer can enable to block a client from hitting a backend via an API. Just in case there’s peak demand or something in the system is struggling. Or maybe you are concerned there’s a widespread Denial of Service Attack (DoS) hitting your system and you want to keep your customer data safe.
What should this kill switch be named? And what state corresponds to the switching off of web traffic?
The enabled state should correspond with the no traffic state. When this kill switch is enabled, the business has gone in and switched it on, effectively switching off traffic. By default this kill switch is disabled and web traffic is normal. You might want to call this kill switch something that relates to the API it switches off, e.g. WebLoginKillSwitch if the kill switch prevents people from login to your web.
Feature Flags
A feature flag is a software development technique used to enable or disable functionality remotely without deploying code.
https://launchdarkly.com/blog/what-are-feature-flags/
Say you are working on a new feature but you are operating in a continuous integration and deployment environment. Once your code is merged in it could be deployed to customers within minutes. But your feature isn’t ready for customers just yet. You can wrap your feature behind a feature flag and enable it for your team so you can test in production even before your customers see it.
By default this feature is disabled for most of your users. But you could also set up a % rollout for the feature too. Maybe 5% of your users see the new feature before doing a general release.
When naming a feature flag you don’t need to include the word enabled or disabled in the variable. If you are experimenting with a new way of web login using apple ID you might call this feature flag webLoginWithAppleID and have it disabled by default.
Read the art of readable code
If you are interested in learning more about readable code, I recommend reading the Art of Readable Code:
Do you have any code smells related to naming of variables? How about test code smells?