• 8 SCSS Best Practices to Keep in Mind
  • Written by Annie Liao
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: snowyYU
  • Proofreader: Onlinelei, Iceytea

Eight useful SCSS best practices

Last week I looked at a company’s code specification, and I saw that some of the rules apply to personal projects as well.

Here are eight best practices that I think are particularly good:

1. Mobile devices have priority

When working on responsive projects, it’s common to write the PC version first, but this can make writing the mobile version particularly painful. Therefore, we should first carry out the mobile style writing, on the basis of the mobile style to the PC side of the style expansion.

Don’t do this:

.bad {
  // Desktop code

  @media (max-width: 768px) {
    // Mobile code}}Copy the code

Do this:

.good {
  // Mobile code

  @media (min-width: 768px) {
    // Desktop code}}Copy the code

2. Define variables ahead of time

When initializing a project, you define CSS variables and mixins to improve the maintainability of the project.

As mentioned in the specification, the following properties often read CSS variables:

  • border-radius
  • color
  • font-family
  • font-weight
  • margin(Spacing, spacing of common grid layouts)
  • transition(Duration, easing) — Mixin is recommended

3. Don’t use it#id 和 ! important

! Important and #id are very overhanded and often mess up the order of CSS rendering and presentation priorities, especially in team development.

Don’t do this:

#bad {
  #worse {
     background-color: # 000; }}Copy the code

Do this:

.good {
  .better {
     background-color: rgb(0.0.0); }}Copy the code

4. Don’t write numbers

Try not to set specific values for properties when writing styles, it may “just fit” in terms of the results of the page rendering. But other developers may not understand why the property must be set to this particular number. Therefore, try to write meaningful expressions or calculations to make this more readable.

For those of you interested, there is a note on CSS Tricks that points out the disadvantages of using specific values.

Don’t do this:

.bad {
  left: 20px;
}
Copy the code

Do this:

.good {
  // 20px because of font height
  left: ($GUTTER - 20px - ($NAV_HEIGHT / 2));
}
Copy the code

5. Good descriptive naming

Many people name CSS based on how the styles appear. It’s actually better to name it according to the structure.

Don’t do this:

.huge-font {
  font-family: 'Impact', sans-serif;
}

.blue {
  color: $COLOR_BLUE;
}
Copy the code

Do this:

.brand__title {
  font-family: 'Impact', serif;
}

.u-highlight {
  color: $COLOR_BLUE;
}
Copy the code

6. Unit when the value is 0

This article may be commented upon for reasons of other norms and personal custom, but to illustrate the importance of norms to a project. This rule requires you to add units when the duration is 0 (this is common when writing CSS effects, such as transition-duration, to specify how long it will take to complete the transition (in seconds or milliseconds)), Do not specify units for values of length 0 (width, height, top, margin, padding, etc.). In addition, add leading zeros to the decimal place. Be careful that the decimal place is not too long, preferably not more than three digits.

Don’t do this:

.not-so-good {
  animation-delay: 0;
  margin: 0px;
  opacity:.4567;
}
Copy the code

Do this:

.better {
  animation-delay: 0s;
  margin: 0;
  opacity: 0.4;
}
Copy the code

7. One-line comments

It is recommended that you add a comment on the line above the attribute you want to describe. Using block-level annotations (/* */) makes it difficult to delete and cancel comments, so use single-line annotations (//) instead.

Don’t do this:

.bad {
  background-color: red; // No comments at the top of attributes
  /* padding-top: 30px; width: 100% */
}
Copy the code

Do this:

.good {
  // Write comments above the property
  background-color: red;
  // padding-top: 30px;
  // width: 100%;
}
Copy the code

8. Nested media queries

To easily locate media query declarations, do not nest them in each selector, but place them in the top-level SCSS selector on this page.

Don’t do this:

.bad {

  &__area {
    // Code

    @media (min-width: 568px) {
      // Code
    }
  }

  &__section {
    // Code

    @media (min-width: 568px) {
      // Code}}}Copy the code

Do this:

.good {

  &__area {
    // Code
  }

  &__section {
    // Code
  }

  @media (min-width: 568px) {
    &__area {
      // Code
    }

    &__section {
      // Code}}}Copy the code

There are only a few specifications that don’t go into detail, but they can be quite important in a project. If you see a CSS specification that you think is awesome, please share it in the comments!

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.