Code in Quarantine

Published on March 31, 2021 (↻ July 14, 2023), filed under Development (RSS feed for all categories).

In the current second paradigm of web development, we often work with components and have a 1:1 relationship of HTML to CSS ^*.

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.

To keep an eye on new and rarely used code, it can be useful to put it in quarantine. The Little Book of HTML/CSS Frameworks (2015, German edition 2019, new living version) describes the background:

[…] 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 team setting)
• Implement additional monitors as well as events (like “fixits”) to identify and get rid of quarantine code

❧ In small projects, we often know 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?

^* This is an artificial relationship that avoids some but leads to other code duplication. Still, it works 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 was intended.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)