Guía de estilo de Sass: un tutorial de Sass sobre cómo escribir un mejor código CSS

Escribir CSS consistente y legible que se escalará bien es un proceso desafiante. Especialmente cuando las hojas de estilo son cada vez más grandes, más complejas y más difíciles de mantener. Una de las herramientas disponibles para que los desarrolladores escriban mejor CSS son los preprocesadores. Un preprocesador es un programa que toma un tipo de datos y lo convierte en otro tipo de datos, y en nuestro caso, los preprocesadores de CSS son lenguajes de preprocesamiento que se compilan en CSS. Hay muchos preprocesadores de CSS que los desarrolladores front-end recomiendan y utilizan, pero en este artículo nos centraremos en Sass. Veamos qué tiene para ofrecer Sass, por qué es una opción preferible a otros preprocesadores CSS y cómo comenzar a usarlo de la mejor manera.

¿Qué es Sass y por qué debería usarlo?

Para aquellos de ustedes que no saben qué es Sass, el mejor punto de partida es visitar la página web oficial de Sass. Sass es un acrónimo de Syntactically Awesome StyleSheets, y es una extensión de CSS que agrega poder y elegancia al lenguaje básico.

Sass es un preprocesador de CSS con muchas funciones potentes. Las características más notables son variables, extensiones y mixins.

Las variables almacenan información que se puede reutilizar más tarde, como colores u otros valores de uso común. Las extensiones lo ayudan a crear "clases" que permiten la herencia de las reglas. Mixins, puedes pensar en como "función". Sass también tiene otras características sorprendentes en comparación con otros preprocesadores, como el uso de declaraciones lógicas (condicionales y bucles), funciones personalizadas, integración con otras bibliotecas como Compas y muchas más. Estas características por sí solas pueden ayudarte a ti y a tu equipo a ser más productivos y a escribir mejor CSS al final.

Por qué necesita una guía de estilo CSS

Desafortunadamente, incluso los preprocesadores no pueden arreglarlo todo y ayudarlo a escribir un buen código CSS. El problema al que se enfrenta todo desarrollador es que las aplicaciones web actuales son cada vez más grandes. Es por eso que el código debe ser escalable y legible, y debe evitar el código espagueti y las líneas no utilizadas del mismo. Para evitar los problemas mencionados, se necesita algún tipo de estándar para su equipo en el trabajo diario. ¿Qué es el código espagueti y cómo sucede? El código espagueti es un nombre para el código malo, lento, repetitivo e ilegible. Cuando un equipo escribe grandes aplicaciones sin pautas o estándares definidos, cada desarrollador escribe lo que necesita y cómo quiere. Además, cuando los desarrolladores están escribiendo muchas correcciones de errores, revisiones y parches, tienden a escribir código que resolverá el problema, pero no tienen tiempo para escribir el código de la mejor manera. En estas situaciones, es muy habitual terminar con muchas líneas de CSS que ya no se utilizan en ningún sector de la aplicación. Los desarrolladores no tienen suficiente tiempo para limpiar el código y se ven obligados a publicar la solución lo más rápido posible. Otra situación recurrente es que para arreglar cosas rotas rápidamente, los desarrolladores usan mucho !important , lo que da como resultado un código muy pirateado que es difícil de mantener, da como resultado muchos comportamientos inesperados y necesita ser refactorizado más tarde. Como ya se mencionó, a medida que el código crece, la situación empeora.

La idea de este artículo es compartir reglas, consejos y mejores prácticas para escribir un mejor Sass. La agrupación de esos consejos y mejores prácticas de Sass se puede utilizar como una guía de estilo de Sass. Esta guía de estilo debería ayudar a los desarrolladores a evitar las situaciones mencionadas anteriormente. Las reglas se agrupan en segmentos lógicos para facilitar la referencia, pero al final debe adoptarlas y seguirlas todas. O al menos, la mayoría de ellos.

Guía de estilo

El conjunto de reglas y mejores prácticas de esta guía de estilo se adoptaron en base a la experiencia de trabajar con muchos equipos. Algunos de ellos provienen de prueba por error y otros están inspirados en algunos enfoques populares como BEM. Para algunas reglas no hay una razón específica por la cual y cómo fueron establecidas. A veces, tener la experiencia pasada como única razón es suficiente. Por ejemplo, para asegurarse de que el código sea legible, es importante que todos los desarrolladores escriban el código de la misma manera, por lo que existe la regla de no incluir espacios entre paréntesis. Podemos discutir si es mejor incluir el espacio entre paréntesis o no. Si cree que se ve mejor cuando hay espacios entre paréntesis, ajuste esta guía de estilo y reglas según sus preferencias. Al final, el objetivo principal de la guía de estilo es definir reglas y hacer que el proceso de desarrollo sea más estándar.

Reglas generales de CSS

Siempre se deben seguir las reglas generales. Se centran principalmente en cómo se debe formatear el código Sass para brindar consistencia y legibilidad del código:

• Para la sangría, use espacios en lugar de tabulaciones. La mejor práctica es usar 2 espacios. Puede ejecutar su propia guerra sagrada con esta opción, y puede definir su propia regla y usar pestañas, espacios o lo que más le convenga. Solo es importante definir una regla y seguir esa regla mientras se es consistente.
• Incluya una línea vacía entre cada declaración. Esto hace que el código sea más legible por humanos, y el código está escrito por humanos, ¿verdad?
• Use un selector por línea, así:

 selector1, selector2 { }

• No incluya un espacio entre paréntesis.

 selector { @include mixin1($size: 4, $color: red); }

• Use comillas simples para encerrar cadenas y URL:

 selector { font-family: 'Roboto', serif; }

• Termina todas las reglas con un punto y coma sin espacios antes:

 selector { margin: 10px; }

Reglas para selectores

A continuación, seguimos con un conjunto de reglas para usar cuando se trata de selectores:

• Evite el uso de selectores de ID. Los ID son demasiado específicos y se usan principalmente para acciones de JavaScript.
• Evite !important . Si necesita usar esta regla, significa que algo está mal con sus reglas de CSS en general y que su CSS no está bien estructurado. Se puede abusar fácilmente de CSS con muchas reglas !important y terminar con un código CSS desordenado y difícil de mantener.
• No utilice el selector de niños. Esta regla comparte el mismo razonamiento que la ID. Los selectores secundarios son demasiado específicos y están estrechamente relacionados con su estructura HTML.

Mantenga sus reglas Sass en orden

Es importante mantener la consistencia en el código. Una de las reglas es que debes mantener el orden de las reglas. De esta forma, otros desarrolladores pueden leer el código con mucha más comprensión y dedicarán menos tiempo a orientarse. Este es el orden propuesto:

1. Utilice @extend primero. Esto le permite saber al principio que esta clase hereda reglas de otros lugares.
2. Utilice @include siguiente. Es bueno tener tus mixins y funciones incluidas en la parte superior, y también te permite saber qué sobrescribirás (si es necesario).
3. Ahora puede escribir sus reglas regulares de elementos o clases de CSS.
4. Coloque pseudoclases anidadas y pseudoelementos antes que cualquier otro elemento.
5. Finalmente, escriba otros selectores anidados como en el siguiente ejemplo:

 .homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }

Algunas convenciones de nomenclatura

La parte de convenciones de nomenclatura del libro de estilo se basa en las dos convenciones de nomenclatura BEM y SMACSS existentes que se hicieron populares entre los desarrolladores. BEM significa Bloque, Elemento, Modificador. Fue desarrollado por el equipo de YANDEX y la idea detrás de BEM era ayudar a los desarrolladores a comprender la relación entre HTML y CSS en el proyecto. SMACSS, por otro lado, significa Arquitectura escalable y modular para CSS. Es una guía para estructurar CSS para permitir la mantenibilidad.

Inspirándonos en ellos, nuestras reglas de convenciones de nomenclatura son las siguientes:

• Utilice un prefijo para cada tipo de elemento. Prefije sus bloques, como: diseños ( l- ), módulos ( m- ) y estados ( is- ).
• Utilice dos guiones bajos para los elementos secundarios de cada bloque:

 .m-tab__icon {}

• Use dos guiones para los modificadores de cada bloque:

 .m-tab--borderless {}

Variables

Usa variables. Comience con las variables más generales y globales, como los colores, y cree un archivo separado para ellas _colors.scss . Si nota que está repitiendo algún valor sobre la hoja de estilo varias veces, vaya y cree una nueva variable para ese valor. Por favor, SECA. Agradecerá cuando quiera cambiar ese valor, y cuando necesite cambiarlo en un solo lugar.

Además, use un guión para nombrar sus variables:

 $red : #f44336; $secondary-red :#ebccd1;

Preguntas de los medios

Con Sass puede escribir sus consultas de medios como consultas de elementos. La mayoría de los desarrolladores escriben consultas de medios en un archivo separado o al final de nuestras reglas, pero eso no se recomienda. Con Sass puede escribir cosas como el siguiente ejemplo anidando consultas de medios:

 // ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

Esto genera un CSS como este:

 // Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

Estas reglas de consultas de medios anidadas le permiten saber muy claramente qué reglas está sobrescribiendo, como puede ver en el fragmento de Sass donde se usan las consultas de medios con nombre.

Para crear consultas de medios con nombre, cree su combinación de esta manera:

 @mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

Puede leer más sobre cómo nombrar las consultas de medios en los siguientes artículos: Nombrar consultas de medios y Escribir mejores consultas de medios con Sass.

Otras Consideraciones

Al final, aquí hay algunas otras consideraciones que también debes tener en cuenta y seguir:

• Nunca escriba prefijos de proveedores. Utilice autoprefixer en su lugar.
• Utilice un máximo de tres niveles de profundidad en las reglas anidadas. Con más de tres niveles anidados, el código será difícil de leer y tal vez esté escribiendo un selector de mierda. Al final, estás escribiendo código CSS para acoplarlo con tu HTML.

 .class1 { .class2 { li { //last rules } } }

• No escriba más de 50 líneas de código anidado: O mejor, no escriba más de X líneas de código anidado. Configure su propia X, pero 50 parece un buen límite. Si pasa ese límite, tal vez el bloque de código no quepa en la ventana de su editor de texto.
• Escriba un archivo principal donde importará todos sus bloques, parciales y configuraciones.
• Importe primero las dependencias globales y del proveedor, luego las dependencias creadas, luego los diseños, los patrones y, finalmente, las piezas y los bloques. Esto es importante para evitar importaciones mixtas y la sobrescritura de reglas, ya que nosotros no podemos administrar las reglas globales y de proveedores.
• No sea tímido y divida su código en tantos archivos como sea posible.

Conclusión

La idea detrás de esta guía de estilo es brindarle algunos consejos sobre cómo mejorar la forma en que escribe su código Sass. Tenga en cuenta que incluso si no está utilizando Sass, los consejos y reglas proporcionados en esta guía de estilo también son aplicables y se recomienda seguirlos si usa Vanilla CSS u otro preprocesador. Nuevamente, si no está de acuerdo con ninguna de las reglas, cambie la regla para que se ajuste a su forma de pensar. Al final, depende de ti y de tu equipo adaptar esta guía de estilo, usar alguna otra guía de estilo o crear una completamente nueva. Simplemente defina la guía y comience a escribir un código increíble.