Sass in the Real World: book 1 of 4

Sass for styles, SCSS for logic

Leveraging the fact that .sass files can live harmoniously with .scss files, some developers have adopted a workflow of, using SCSS for all logic (mixins, extends and functions) and then using Sass for the CSS styling.

When writing style rules for your design, Sass is quick and get's the job done. Less key strokes and a quick tab in for nesting are all great things when writing code. An added benefit of Sass is the ability to quickly redefine a series of selectors and/or rules by simply changing the level of indentation, versus having to redefine nesting by moving around curly-brackets { ... }. Let's face it, if you are using Sass, writing CSS should pretty much roll off your fingertips. Writing out selectors and rules is sans logical thought process and you are simply executing output at this time.

On the other hand, when it comes to complex thought processes, the use of curly brackets { ... } has been stated to assist in a developer's ability to see the logical code groupings I have found that using the SCSS syntax when writing logical code helps me to slow down and really take a hard look at the code I am writing.

Good code habits include writing comments and Sass is no different. SCSS allows for comments to be placed inline with the line code you are referencing. Due to the whitespace specifications, this is not possible in Sass. SCSS' form of commenting allows developers to really be expressive in their notes.