Judging CSS / Spotting Bad Code

Avatar of Chris Coyier
Chris Coyier on (Updated on )

In a recent Q&A article on Smashing Magazine, a question was asked about how to tell if a developer has written bad CSS. Specifically:

What are the signs that the CSS is sub-optimal, or that the developer hasn’t done a good job? What do you look for in CSS to determine how good or bad it is?

I thought that was an interesting question and I’d expound upon my answer a bit.


Perhaps you’ve hired someone to write CSS for you and you want to have a gauge of how good they did. Perhaps you’re looking through someone’s CSS that you may potentially hire. Perhaps you want to gauge your own CSS somehow.

The Obvious Test

Look at the website. If it looks all messed up, then they did a bad job.

Taking that a step further, check it against the browsers you agreed on would be supported. The design should be workable in all of them.

If the design is supposed to be responsive, resize your browser window to ensure the design works no matter what width or height it is.

If everything looks good, that’s a good (and required) first step. But it’s not absolute proof the CSS is good.

The Formatting Test

Take a look through the authored CSS file. Remember that it’s best practice to serve the live website minified CSS (all non-important whitespace removed), so don’t look at that.

That’s not intended to be read by humans. Look at the file that they actually created.

If you have an established style guide that was expected to be followed, was it followed?

If not, does it look consistent – as if they had a style guide of their own that they adhere to? Or is it a bit sloppy? Sloppy meaning sometimes there is one space after selectors and sometimes there is none. Some blocks of code are indented and others aren’t. Single line CSS is mixed with multi-line CSS with no rhyme or reason.

Clean code is the sign of a respectful developer. One who has a respect for the craft and the work they do.

From Nicolas Gallagher’s Idomatic CSS

If these first two test pass, that’s great. But still not quite proof the CSS is good.

The Selector Test

Those first two tests could be done by just about anybody, but from here out you’ll need to have familiarity with CSS yourself. Start reading the CSS and see if what you’re seeing makes sense to you.

Do the selectors look rational? If you see a selector like

.article #comments ul > li > a.button {
  /* Crazy town */

I’d worry. That is a developer fighting themselves with specificity problems, something good CSS doesn’t do.

How are the class names? Understandable? Hopefully you don’t find anything like “bigGray” or “left50” as the accuracy of those will be surely be short lived making for confusing future development.

How repetitive is it? For example, if you see the exact same box-shadow applied in 20 disparate places that’s probably a sign of lack of refactoring. Good CSS developers sense patterns like that and accomodate them better.

The Size Test

How is the file size of the deployed CSS? 100k would be absolutely enormous for a CSS file. Small is good. Even (especially) on complex sites. Huge files is often a sign of lack of consistency.

The Editing Test

Come up with a style you’d like to change on the site and attempt to change it yourself. For instance, swap the all the fonts in use with other fonts. Were you able to familiarize yourself with the code quickly? Did it feel like there was a plan for how fonts were handled in place? How quickly were you able to do it? Faster or slower than that kind of thing normally takes you?

How do you do it?

Have you ever been in the position to judge other’s CSS? Did you use similar tests? Did you have more defined metrics?