10 Tips for Writing Better CSS Code

In this article I want to talk about 10 different ways you can write proper and clean css code as well as streamline the process and ensure you’re getting the job done as quickly and efficiently as possible.

1. Always start with a CSS Reset

Writing CSS code can become a bit mundane when you’re having to write specific code over and over again just to get various browsers to display your layout the same. That is where CSS Reset’s come into play. With industry leaders likeEric Meyerreleasing a pretty kick ass css reset stylesheet, there’s really no reason to not get all of your browsers ‘back to zero’ and build off of it. Some people have said that css reset stylesheets aren’t needed, but once you get used to the reset and what items you’re coding, it becomes much easier to ensure that every browser is displaying items properly.

2. Indent your css rules for easier scanning

When you’ve got 500 lines of css code to sift through, it can become straining on the eyes. So, instead of writing out the css code like this:

3. Comments are your very best friend

In the spirit of keeping your stylesheets clean and easy to read, comments are going to be a great way for you to keep things structured and clean. By commenting out blocks of code, the scanning process we mentioned above becomes another 10X easier because you can scan and look for items such as the header, sidebar, content and footer code because you have each section of code commented like below.

/********** HEADER code here **********/

Doing this will not only save you time scanning but will be great for your clients when you pass along the code – they’ll be able to find items easier, fix items themselves and not have to email you 4-5 times a week for simple 1-2 minute changes. The benefits of clean css code goes much deeper than making the file look pretty.

4. One Rule = One Line … Multiple Rules = Multiple Lines

Following the simple rule above, you can cut down on the clutter in your css files drastically. Below you will see the two different ways you can write your css code out – some people swear by putting everything on a single line, but I tend to believe in the above mentioned rules: one rule = one line, while multiple rules = multiple lines.

5. Stay consistant with your code

I’ve not only stayed cosistant in my css styles throughout stylesheets I’ve written, but if you look at the various css code I’ve displayed in this article, you’ll see I have actually stayed consistant with them. It isn’t something you’ll tend to visually notice on a daily basis, but over time you’ll begin to pick up patterns on how you write specific lines of code and it will throw you off if you ever write something different. It makes things harder to find and runs your time up when you could have easily cured the problem by sticking to a specific style of writing for your css stylesheet files.

For instance, if you’re writing everything in blocks of code to separate different items of the page for easy editing, keep with it. Don’t change the way you write your code every time you write a new stylesheet. It’s just not practical.

6. Separate your hacks and conditional elements

Some people will swear against using any css hacks and scream something like “if the user can’t upgrade his browser, to hell with him!” – which we all know is not something everyone is in the position to say. So, writing conditional elements and various css hacks in your files becomes pretty much routine. But the idea that all of it needs to be in one file is wrong (in my opinion). Separating them from your main style.css file will allow you to make edits and adjustments to the hacks and conditional elements easier, without effecting your main css code.

A sample of how to separate your files could be like the code below, which would give you a separate stylesheet if your viewer is using any internet explorer browser less than IE8, along with your main style.css file and a print.css file (make sure you add the proper “” characters at the beginning and end of each line in the code below):

7. Learn (and use) shorthand code

Shorthand css code will allow you to speed up the writing process, cut down on clutter in your stylesheets and will allow you to find things much easier. So, why do so many people still write out their css in a long hand format like this?!?!

Writing the above code in shorthand format allow things to look so much cleaner. Shorthand code also follow the clockwise writing format – so each number (as seen below) goes like this: top, right, bottom, left.

.classname { margin: 1px 2px 4px 1px; }

8. Create and use a table of contents

Writing in a table of contents in the beginning of your stylesheet will allow you, as well as anyone else viewing your css file, to find where the specific items in your code are before they even have to scroll. Need to find and edit your content code to change a color of a specific piece of text? Looking at the table of contents shows you that it’s the third header down in the css file. Coupled with the rule from above about adding in commented areas to separate blocks of code, this will help keep your code lean and mean – plus, very easy to edit.

9. Keep your class and ID names easy to follow

Picking the proper naming structure for your css classes and ID’s can help you dig through your stylesheet files as well as your html files, to edit the code. I would recommend sticking with names like this, which keep things clear and easy to understand:

.sidebar-title { ... }
.postwrap { ... }
.main-navigation { ... }

10. Alphabetize your css code for easier reading

This is one tip that I’ve just come to realize is actually worthwhile and one that I’m beginning to use on a daily basis when writing css code. Alphabetizing your rules will allow you to easily jump in, find the proper line of code you need to edit, change it and move on. Check out the code below and see how the beginning letters of each line go in alphabetical order, which allows you to easily scan and find the proper line. Looking for font-size? well, you know where F comes in the alphabet, right? So finding it in these lines of code will be much easier.