Commenter

La charge cognitive du travail avec CSS est énorme. Avec tant de choses dont il faut être conscient, et tant de nuances spécifiques aux projets dont se souvenir, la pire situation dans laquelle se trouvent les développeurs est d'être la-personne-qui-n'a-pas-écrit-ce-code. Ce souvenir de ses propres classes, règles, objets, et aide et possible a un certain point, mais toute personne qui hériterait de code CSS n'a quasiment aucune chance de faire le poid.

Le CSS à besoin de davantage de commentaires.

Le CSS is something of a declarative language that doesn’t really leave much of a paper-trail, it is often hard to discern—from looking at the CSS alone—

Si le CSS dépend de code hors de là où il est écrit;
Quels effets un changement de code aura ailleurs;
Où ailleurs ce CSS pourrait être utilisé;
De quels styles quelque chose peut hériter (intentionnelement ou non);
what styles something might pass on (intentionally or otherwise);
Où un auteur a prévu qu'un morceau de CSS soit utilisé.

Et cela ne prend mêem pas en compte la plupart des nombreux bugs de CSS — comme comment plusieurs état d'overflow triggering block formatting context, or certain transform properties triggering hardware acceleration—that make it even more baffling to developers inheriting projects.

Le résultat du CSS n'explicitant pas très bien son fonctionnement, c'est un langage qui gagne vraiment à être fortement commenté.

Vous devriez adopter comme règle de commenter tout ce qu'il n'est pas immédiatement évident dans le code nu. C'est à dire, il n'y a nul besoin de préciser que color: red; rendra quelque chose rouge, mais si vous utilisez overflow: hidden; to clear floats—as opposed to clipping an element’s overflow—this is probably something worth documenting.