Code in Quarantine
This component-based 1:1 approach looks like it makes maintenance more predictable. That is, fewer stools seem to fall over in other bars. However, it doesn’t solve—but rather pronounces †—the problem of rarely used code.
Next, new and rarely used patterns are a challenge that runs in the best families. There tends to always be a need for something new, and there are always document types or elements that are used infrequently. They’re one of the biggest contributing factors to code bloat. They are hard to control if they don’t get watched and reigned in vigorously. Though I could give a longer dissertation about the matter, an effective counter-practice is to either designate style sheet and script sections for new and experimental code, as well as rare elements—or to even put aside a separate style sheet and script for such purposes. The framework developers should anticipate this and make recommendations, but users should come up with their own guidelines if this piece has not been covered. A documented standard for new code allows better monitoring and better decisions on whether to keep (and relocate) the code, or to remove it.
What does this mean? What is code in quarantine?
Code in quarantine is code visibly marked as experimental, in test, or defective. ‡
From here on, quick thoughts:
What Code to Put Under Quarantine
What code would you actually quarantine?
- Anything you’re using for the first time and don’t know you’re going to use at other times
- Anything experimental
- Anything hacky
- Anything suspicious (ideally not outright insecure—that needs immediate attention)
How to Mark Code in Quarantine
There are several approaches to quarantining code:
- Define one or more quarantine identifiers to use for naming (“test”, “experimental”, “quarantine”)
- Mark quarantine code with comments, using the respective identifier; these comments can be to-do comments and involve action items (“TODO”, “@@”)
- Place it in special files, using a quarantine identifier
- Place it in special folders, using an identifier
How to Proceed with Code in Quarantine
Finally, you can go about quarantined code in various ways:
- Call out quarantined code in the build or deployment process
- When augmenting the process to use timestamps, issue warnings and, after a given time, errors about code in quarantine
- Set reminders to regularly review the respective code (which could happen both in an individual and in a group setting)
- Implement additional monitors as well as events (like “fix-its”) to identify and get rid of quarantine code
❧ In small projects, we often know the code well enough to avoid quarantining portions of it. To-do comments may be enough to keep an eye on them. In larger projects, it’s easier to lose track of anything that is or could be a problem. Here, having a model that goes beyond to-do comments is useful.
The ideas above have helped some of the projects I’ve worked on. What helped yours? What did you observe?
Figure: Let’s make sure quarantine code doesn’t feel like that, either. (Copyright King Features Syndicate, Inc., distr. Bulls.)
* This is an artificial relationship that avoids some but leads to other code duplication. Still, it seems to work for many developers.
† How would the problem of code duplication be pronounced? Many components may contain the same declarations. These may then not be normalized anymore, that is, be merged as CSS rules. (If we were talking about the first paradigm, this would have led to the recommendation to vigorously DRY all CSS.)
‡ Quarantine code is actually different from “shame” code, though that label may come off stronger than the inventor wanted it.
I’m Jens Oliver Meiert, and I’m a web developer (engineering manager) and author. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have questions or suggestions about what I write, please leave a comment (if available) or a message.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out some of the most important aspects of such CSS. Available at Amazon, Google Play Books, and Leanpub.
Looking for a way to comment? Comments have been disabled, unfortunately.