Naming CSS Classes by Purpose or Effect

What’s the best way to name a css class: form-field-label or bold-text? Is there any difference between MVC’s EditorFor and TextBoxFor? Or between a DetailedRowText property and ArticleDescription?

For all the cases, there is a difference. The first one is naming by purpose and the other naming by effect, or what it actually does. Even though the methods/properties do exactly the same thing, there’s a huge difference in the coupling they imply. When named by effect, the name is a promise to the caller on exactly what will be done. It is safe to use it in different circumstances, trusting that it will always do what the name implies. When a method is named by purpose there’s no guarantee on exactly what it will do, there’s instead a promise that it will adopt it’s behaviour as needed.

Both naming by purpose and naming by effect have their uses, but they shouldn’t be confused. The choice between them should always be deliberate and not accidental.

Let’s look closer at the examples listed above.

CSS Class Naming

Before looking at the first example, the css class naming, let’s take a little detour on the purpose of CSS. Have you ever had to work with a web page that doesn’t make use of css? There’s style="..." attributes all over the place. Even a very simple change like the colour of headings is a major task as it will require the style attribute of all headings in all pages of the entire site to be changed. CSS Classes are meant to remedy this. Unfortunately it is possible to use CSS classes, but still have a site that’s hard to change.

If it’s your task to redesign a site so that all labels for form fields are now italic instead of bold there’s a huge difference between having CSS classes form-field-label or bold-text. In the former case you can just change the styling of form-field-label. In the latter you could try to change bold-text into now meaning italics but it would both be extremely confusing and error prone as there might be other bold text that should still be bold.

For CSS classes my preference is clear: Always name by purpose. Naming by effect is just another syntax for emedding style="..." attributes right in the code. Technically CSS is used, but all the cons of having the styling in the code are still there.

With the new HTML5 semantic tags and hierarchic selectors there’s often not even any need to make css classes. The HTML structure alone is enough to make a CSS selector that styles the element.

MVC’s EditorFor vs TextBoxFor

The next example is from MVC, where there are two methods that will (in most cases) do the same thing: Produce a simple input box where text can be entered. The difference is that with TextBoxFor we can be sure that it will always be a text box, while with EditorFor custom editor templates might change the behaviour as needed for a specific type. I mostly use EditorFor in my views because I do want to be able to customize my views through editor templates.

DetailedRowText vs ArticleDescription

When working on a view model recently for a kind of order system I had to show the description of the article on an order row. I could have named the view model property ArticleDescription but that would require me to change all views if I later would like to add some more information to the rows. Instead I chose to name the property DetailedRowText as that allows me to later add more text to the property without breaking the contract implied by the naming.

Two Levels of Naming

In some cases, it makes sense to have naming in two layers. The lower layer contains the methods that actually do the work. They are named after what they do(TextBoxFor). On top of that, there’s another layer that maps behaviour to functionality (EditorFor). Using separate layers with separate naming schemes helps decouple the system and makes it easier to change behaviour of similar functionality spread across an entire application.