Naming conventions ultimately come down to personal preference, but you have to imagine that someone at some point will be looking at your work so it needs to be “legible”. Good code is commented, adheres to industry best practices, and allows for others to easily understand its purpose. I’ll be taking a look at some examples and best practices for all languages and a focused look at CSS, my primary language as a front-end developer.
It’s never a good idea to arbitrarily choose a name, no matter how clever you think you are. Names should always be semantic; they should be simple to interpret and logically make sense within the context of what you are working on.
Prefixing is a great way to protect against conflict from plugins and third party resources. This works by appending the name of the project, author, or section to the beginning of classes and IDs. It can, however, make the name very long and unwieldy. Consider the size of the project, the specificity needed and extensibility.
Each language has its own set of rules for naming. With so many languages and rules, remembering everything can get rather frustrating. For instance, PHP variables cannot have dashes, only underscores, whereas CSS can have dashes and underscores. Multiple word names can be differentiated with dashes, underscores, camelcase (the first letter in each word is capitalized excluding the first) or pascalcase (each word is capitalized including the first). Single word names can be all lowercase or all uppercase.
There is still, however, plenty of leeway in developing your own set of rules and standards within the given parameters. What is most important is picking one method and sticking with it throughout a project. On a team, collectively choose the convention and carry that throughout every project.
IDs vs. Classes
As a general rule of thumb, classes are the preferred selector for styling because they are extensible; whereas only one ID is allowed per element and cannot be reused in the same page. Classes can be chained together within one element and reused an infinite number of times.
BEM (Block, Element, Modifier) is a popular industry standard for naming using prefixing, underscores and dashes.
.blockrepresents the higher level of an abstraction or component.
.block__elementrepresents a descendent of
form.blockas a whole.
.block--modifierrepresents a different state or version of
- Classes and IDs must begin with a letter.
- Classes and IDs are case-sensitive.
- Punctuation is allowed but # and . should be avoided as these are used for targeting IDs and classes.
Real World Example
Let’s take a look at some methods that the popular WordPress ecommerce plugin, WooCommerce employs. To be honest their naming conventions can be a bit all over the place. At least some of this disparity due to its open-source structure.
- Some classes use dashes, some classes use underscores (primarily for tables, widgets and forms though the reasoning is unclear).
- Names are too similar like
.products. To help differentiate the selectors for styling they use
ul.productswhich are not necessary.
- Nearly every selector is nested under the body classes of
.woocommerce-pageadding a lot of unnecessary bloat, especially for classes and IDs that are already prefixed with woocommerce.
- Some IDs like
#contentare too common and thus are susceptible to conflict.
My two cents are as follows: HTML should be written in all lowercase, thus CSS should also be written in all lowercase. Since dashes are not used in PHP, I use dashes in CSS to separate words rather than underscores. Prefixing like items such as buttons is preferable so you might have classes like
.btn-blue. BEM is a nice method but the syntax can be a bit confusing.