Code in Quarantine

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

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?

How to Mark Code in Quarantine

There are several approaches to quarantining code:

How to Proceed with Code in Quarantine

Finally, you can go about quarantined code in various ways:

❧ 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?

When kingdoms totter and thrones tremble, when battles are fought and people everywhere are acting important, it is quite possible that some people get overlooked.

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 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.

Toot about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (where applicable) or a message.