SASS Style Programming Guide for CSS

As more and more developers use SASS, we need to pay attention to the number of SASS codes. We can start from the syntax of CSS (Cascading Style Sheets) to explain some of the special features of SASS syntax. After all, CSS style guides are very common.

This article mainly introduces some features that I am personally interested in. Maybe you can benefit from it and form a set of SASS usage guidelines of your own.
Continue to follow your usual CSS formatting rules and style guides

This article focuses on some content about SASS, but on this basis, developers should maintain their existing and good formatting rules. If you haven’t developed your own set of formatting rules yet, here’s a roundup of some style guides that should help you develop your own CSS writing habits. Here are just some of what is included:

1. Keep line indents consistent
2. Keep the number of spaces before and after colons/curly braces consistent
3. Keep one selector per line and one rule per line
4. Try to write related attributes together
5. There is a plan for class naming rules
6. Avoid using CSS id selectors
7. Wait

Next, let's learn how to write beautiful SASS code. Take writing a property of the .weather class as an example:
List @extend(s) first

Doing so can enable developers to keep a clear mind, immediately understand the relationship between this class and its attributes and other classes and their attributes, and maintain consistency of attributes and clear ideas for attribute reuse.
Normal style

Doing so allows developers to see at a glance the deployment of @extend(s) and @include(s), making it easier for themselves and other developers to interpret the code. You may also decide whether to distinguish between custom @includes and @includes from public sources in some cases (especially considering code reusability and timeliness).
Selector nesting

Within the nested section, continue to use the style rules described above. Nested sections should always come last.
All vendor prefixes use @mixins

Manufacturer prefixes (CSS prefixes) are very time-sensitive. As modern browsers update, these prefixes will be used less and less. You can adapt to these changes by updating the content of your mixins (or some libraries used in your mixins will be updated automatically). It doesn't matter if the mixin is only one line long.
But when some vendor prefixes are heavily privatized, these prefixes will be very difficult to standardize and applying other prefixes or unprefixed versions will not be worth the effort. I will choose to abandon @mixin these vendor prefixes. For example, -webkit-line-clamp, -mscontent-zoom-chaining or similar.
The nesting level should not exceed 3 levels.

If you nest more than three times, you are very likely to have written a bad (bad?) selector. The reasons for this failure are that the selector is too dependent on the HTML architecture (unstable), too detailed (too powerful and inflexible), or too difficult to reusably use (not very usable). At the same time, too many nested levels can easily make the code obscure and difficult to understand.

Sometimes there is so much class-related code that you have to use tag selectors. You may need to be very specific about what you are writing for a class to avoid unnecessary cascading. It’s even possible to use extend to take advantage of some of the reusability features in CSS.

The number of nested code should not exceed 50 lines.

If the nesting in SASS exceeds 50 lines, it may not be fully displayed on one page of the compiler, which will make the code difficult to read and understand. Nesting was originally intended to facilitate and simplify thinking and code organization. If it is against readability, please do not nest.
Global and localized SASS file sequences are equivalent to table contents

In other words, they don't have any one fixed style. Developers should remind themselves to keep the style of all parts consistent and orderly.

The vendor/global libraries are listed first, followed by the custom libraries, then the modes, and finally the libraries used by each division.

This way the 'directory' looks like the following example, which is very clear at a glance:

These files are like a compass, colors and mixins do not generate compiled CSS code, they are purely independent libraries. Patterns were introduced after this to make rewrites safer without conflicts of exclusivity.
Split SASS into multiple small files

There is nothing wrong with doing this. Whenever possible, use multiple small and precise files. This makes it easier for developers to find specific files instead of searching for a needle in a haystack among several large files with lengthy code.

...

What I often do is to reference these files one by one in a global scss file, instead of referencing a _header.scss file and then referencing them one by one in the _header.scss file. Doing so can reduce indexing time and improve reading efficiency.

When there are too many of these files and the import sequence is too long, you might want to use Globbing.
Remember to name the Partials as _partial.scss

This is a common naming convention for files that do not compile themselves. Such files will be more or less dependent on other files, making it impossible to compile independently. I personally like to add an underscore before the file name, such as _dropdown-menu.scss
Add line mapping when compiling locally

See here, this means that the development tools can tell you the source of each rule, even if it is an imported partial file.
When deploying, remember to compile the minified files

A working web page should only ever use minimal CSS.
No need to submit .css files

This may take some time, but not having .css files in your repository can be a wonderful thing. Compilation is done at deployment time. So the only thing you can see are those beautifully formatted sass files that have been minified. This makes the description of the file very useful. File descriptions are used to compare changes made by the version publisher. For the already streamlined .css files, the file description is basically not needed.
Generous usage notes

Few people regret leaving comments in their code. Whether useful or insignificant, comments will eventually be erased when compiled into minified CSS files, without any additional cost to the developer.

.overlay {
/* modals are 6000, saving messages are 5500, header is 2000 */
z-index: 5000;
}

Speaking of comments, you may also want to make some standardization adjustments to them. In SASS, '//' is very suitable for adding comments. '//' makes commenting and uncommenting very convenient.
Convert some commonly used values ​​and values ​​with special meanings into variables

If you find yourself reusing a value (which is very common in front-end design), you're better off turning it into a variable. This way you can remind yourself what the value means by naming it, and stay consistent when writing code, so you don't have to adjust it line by line when changing the value.

If a number has an obvious meaning, then converting it into a variable is essential.

These figures may be stored in a single file and imported as @imported. This way you can manage all z-index or other variables in a unified way
Converting colors into variables

Except black and white. Many colors are used more than just once, even if you think you won't use them again. But if you convert it into a variable, you might find that you need it in other places. For color variables, there are color functions in Sass that can handle them, such as lighten() and darkern(). This makes it easy to control the overall color (change once, and forget it)
Nest and name your media libraries

The ability to nest media libraries in Sass means 1. you don’t have to override selectors somewhere else and cause unnecessary errors; 2. it’s clear what rules you’re overriding, which can get very confusing when it’s at the end of your CSS or in another file.

A more detailed explanation is here: http://css-tricks.com/naming-media-queries/
Put Shame Last

In your global stylesheet, import a _shame.scss file at the end.

If you need to make some quick changes, you can do so here. If you have the time and energy later, you can
The changes made to the overall architecture in _shame.scss are better organized and structured. For more details, please see: http://csswizardry.com/2013/04/shame-css/
You are the one who decides everything

Sass won't do anything you don't tell it to, so the final output of your Sass file is up to you. Writing CSS files with Sass is just like writing CSS files without Sass. You are the master of the code.