it's common courtesy, really

Best practices make everybody's lives easier, everybody being other developers and future you. Other developers and future you have a significant commonality: trying to figure out what the hell is going on with your code. Trust me, just because what you're writing makes sense to you now, it won't when you come back to it in three months. Other developers also greatly appreciate your use of best practices, whether you work with them or they are forking your repos. This post happens to be inspired by working with other devs. That's not to say all of the points I make here are because of poor practice, in fact, some are because I have seen them done particularly well.

There are many best practices, such as making your code performant, responsive, and cross-browser friendly. However, we'll save those for other posts. I'll be focusing on those that jump out at me. Let's dive in.

Alphabetize Properties

When I first started coding, I organized my properties based on what I thought went well together, for example:

  
/* sad code */
.adorable {
  color: turquoise;
  background-color: #aaa;
  height: 30px;
  width: 30px;
  display: block;
  position: relative;
}

Color themes, sizing, positioning, etc. At the time, it made sense to me, and it worked well enough because I went one small, solo project at a time. Now I work in a colossal code base with many stylesheets from multiple projects and a slew of developers. Code is constantly being updated, and styling bugs are found pretty readily. Developers get very focused on styling an individual page or aspect in their corner of the website, and it can be hard to know what other corners are affected. When I get assigned one of these bugs, I go bug hunting in Chrome tools. I already have enough styles and sheets to sort through, so alphabetized properties make it a hell of a lot easier to find where a particular suspected property is located.

Here's an example. I've noticed that one element is getting cut-off on the page. I suspect that the element has a (probably) unnecessarily defined height, so I right click and inspect the element. Now I am looking for a height property in what could be .adorable, span.adorable, span ~ .adorable, and all inherited styles from the HTML element and its ancestors. So having rule sets that look like this:

  
/* happy code */
.adorable {
  background-color: #aaa;
  color: turquoise;
  display: block;
  height: 30px;
  margin: 0 auto;
  width: 30px;
}

makes for a very happy investigator.

Group Selectors

Don't alphabetize your selectors. Instead, try to order them as you see them in the HTML or on the rendered page. For example, a header would likely come first, followed by anything that may be contained in it. The only thing that might precede it is general selectors. An example:

  
body {
  background-color: #eee;
  color: #777;
  font-family: 'Lato', sans-serif;
}
h1, h2, h3, h4, h5, h6 {
  font-family: 'Avenir', sans-serif;
  text-align: center;
}
div {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}
a {
  text-decoration: none;
  &:hover {
    color: #c69;
  }
}
.header {
  background-color: #777;
  color: #eee;
  padding: 1rem;
}
.main-content {
  margin: 0 auto;
  width: 80%
}
.footer {
  bottom: 0;
  position: absolute;
}

Notice how I went through and predetermined some styles that I would generally want for this page, such as reformatting the links and setting fonts. After that, I went through my page and formatted each element piece by piece.

Putting your general selectors at the top helps with your organization and easily overriding your boilerplate styles for specific parts of your page.

Divide your code

If you find you're getting an exceptionally long stylesheet, group your code together and put it in a separate file. A good common example would be dividing CSS that is specifically for the footer into a footer.css file, or if you're being Sassy, a _footer.scss file (don't forget to @import your stylesheet).

Descriptive selectors

Selectors should give you more information about what you're selecting. For example, .header-container is much better than .parent. Probably anything is better than .parent outside of simplistic learning and playing purposes. Name your classes based on what styling they require. For example, if you saw the selector #profile-pic or .recipe-ingredients-block, just those names alone give you an idea of not only what the page is about, but what that particular element on the page is doing.

Reusability and Playing Nicely

You really, really want elements to play nicely with each other, and for your code to play nicely with other code. That means elements will adapt and still look nice as things change around them, and your code isn't destroying other code. Code should be a war-free zone. Reusability is also highly desirable as it means you write less code that has the same effect.

Classes vs. ids

Ids are to be used once and only once per page. If you are styling using an id as a selector, only alter properties that are specific to that element. Throw everything it shares into classes that make sense. For example, we could have:

  
$theme-pop-color: rgba(10, 145, 80, .3);

 .header {
   color: $theme-pop-color;
   height: 50px;
 }

 .sidebar {
   display: fixed;
   height: 100vh;
   right: 0;
   width: 30%;
 }

 .theme-bars {
   background-color: $theme-pop-color;
 }

Bootstrap* does an excellent job of this. In fact, the whole styling system is based of off this concept.

*For those of you who are not familiar, Bootstrap is a style library that you simply need to link to your project. Bootstrap includes CSS and some JavaScript components (ex. incorporating modals). The idea is that you add classes to your HTML and the styling is done for you, making the styles very reusable. Personally, I prefer custom CSS (which you can still add to Bootstrap) and not having a mess of divs in my HTML.

!important

Avoid whenever possible. Adding !important after one or two lines might be ok, but it is very likely that your !important, being as important as it is, will overwrite other styles you try to implement, which can get pretty tricky and frustrating to undo.

You especially want to avoid !important when working with a large codebase or with code where certain elements and classes are commonly used as selectors.

If you are unsure how to make your style override others, I plan to write a post soon on specificity to offer some guidance.

Sass specific

Use the tools Sass gives you to DRY up your code. Use variables and keep them in one place (like a _variables.scss file). This makes finding them and changing your color scheme, for example, very easy. The same goes for mixins and functions.

How about you?

What do you like to see when reading others' code?


758 0 0