Mejores prácticas en CSS: organización y convenciones de nomenclatura

He estado escribiendo código durante más de tres años. Siempre me he preguntado sobre las buenas prácticas y cómo podría hacer que mi código sea más legible, comprensible, fácil de mantener y de ser manejado por otros desarrolladores.

Pasamos más tiempo leyendo nuestro código que escribiéndolo porque siempre buscamos el elemento que podemos modificar, mejorar o simplemente recordarnos cómo funciona este o aquel elemento. Por lo tanto, es importante escribir un buen código, en otras palabras, un código limpio, consistente, extensible y correcto.

Escribir un código no es tan fácil como parece. Sin algunas reglas de escritura, uno puede encontrarse con un código complicado de leer y difícil de depurar. Por lo tanto, difícil de mantener y evolucionar con los efectos nocivos en el rendimiento del software, de ahí la importancia de optimizar nuestro código, en otras palabras, un código que permee las buenas prácticas. Entonces, ¿cuáles son las buenas prácticas en CSS?

usar riguroso

Stickler es una poderosa herramienta que permite a un desarrollador respetar los estándares de codificación establecidos antes de la realización de un proyecto por sí mismo o por su equipo de trabajo. Antes de escribir un código de línea, la mayoría de las veces los desarrolladores establecen estándares de codificación que seguirán para realizar el proyecto en el que quieren trabajar. Esta herramienta interviene en varios aspectos, especialmente en las mejoras de la sangría del código, la corrección de errores de sintaxis y la identificación de lugares donde hay una duplicación del código.

Stickler es utilizado por una amplia comunidad y es bastante flexible en su configuración.

Segmenta el CSS en múltiples archivos

Es muy recomendable cortar su código CSS en muchos archivos, cada uno correspondiente a un módulo, una vista o una página de su aplicación. La elección del corte es libre en función de lo que te parezca más pertinente.

El corte del código en archivos permite navegar fácilmente cuando tenemos que ampliar, modificar o crear nuevas declaraciones.

Ejemplos:

 homepage .css header .css footer .css archive .css

Los méritos de dividir el CSS en varios archivos y aumentar aparecen principalmente cuando alguien usa un preprocesador CSS ( Sass o Less )

Entendiendo la especificidad

La especificidad determina qué regla CSS debe aplicar el navegador. Es una jerarquía, no necesariamente intuitiva en el orden de aplicación de las reglas CSS.

Es importante tener en cuenta que todos los selectores deben declararse con la menor especificidad posible. Esto facilita la reutilización del selector y reduce la dependencia de otro selector.

Preferir :

 .myclass {...}

más bien que:

 body .page .main .sidebar article > .myclass {...}

En la mayoría de los casos, esto evitará que tenga que lidiar con conflictos específicos de CSS.

Estar SECO

No te repitas (DRY, oa veces no te repitas) es un principio de desarrollo de software destinado a reducir la repetición de códigos o patrones de software.

El principio DRY es simple de entender: "Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema".

Ejemplo :

 .texte-erreur { font-size : 15px ; background-color : #ccc ; border-color : red; color : red; } .bloc-erreur { width : 250px ; height : 250px ; background-color : #000 ; font-size : 17px ; border-color : red; color : red; }

Observamos que dos clases comparten sus propiedades border-color y color. Podemos considerar que siempre se encuentran juntos durante un determinado número de clases. Luego podemos crear un mixin y las siguientes clases:

 mixin erreur-base () { border-color : red; color : red; } .texte-erreur { font-size : 15px ; background-color : #ccc ; @include erreur-base(); } .bloc-erreur { width : 250px ; height : 250px ; background-color : #000 ; font-size : 17px ; @include erreur-base(); }

Acabamos de ganar legibilidad y refactorizamos nuestro código para evitar repeticiones.

Convenio de denominación

Nombrar cosas nunca es fácil y la nomenclatura de clases y atributos de identificación en CSS no es una excepción. El problema de los malos nombres es que luego es difícil encontrarte en su código, por lo que es importante encontrar una convención particular para organizarte bien.

Durante mis investigaciones sobre este tema, identifiqué dos convenciones de nomenclatura populares, en particular, OOCSS y BEM .

OOCSS

La programación orientada a objetos (POO) es un paradigma de programación que se enfoca en crear objetos reutilizables y establecer relaciones entre ellos, a diferencia de la programación procedimental que organiza el código en procedimientos (rutinas, subrutinas o funciones).

El CSS orientado a objetos fue propuesto por la desarrolladora web Nicole Sullivan en 2008.

No es ni un preprocesador ni siquiera un nuevo lenguaje, sino más bien una filosofía de código.

 OOCSS PRINCIPLES:

1. La separación de “ estructura ” de “ piel ”
2. La separación de “ contenedor ” de “ contenido ”

 CONTENT - SKIN :

1. Defina los patrones “ visuales ” repetitivos como “ pieles ” reutilizables
2. Definir los patrones “ invisibles ” repetitivos como “ estructuras ” reutilizables

 /* structure */ .btn { display : inline-block; font-weight : 400 ; text-align : center; white-space : nowrap; vertical-align : middle; -webkit-user-select : none; -moz-user-select : none; -ms-user-select : none; user-select : none; border : 1px solid transparent; padding : 0.375rem 0.75rem ; font-size : 1rem ; line-height : 1.5 ; border-radius : 0.25rem ; transition : color 0.15s ; }

 /*SKIN*/ .btn-success { color : #fff ; background-color : #28a745 ; border-color : #28a745 ; } .btn-danger { color : #fff ; background-color : #dc3545 ; border-color : #dc3545 ; } .btn-warning { color : #212529 ; background-color : #ffc107 ; border-color : #ffc107 ; }

 CONTAINER - CONTENT

Un objeto no debe depender de la ubicación donde lo coloque: a menudo es la causa principal de la duplicación de código.

 .announcecategory > div :nth(3) { color : red; /*...*/ /*BAD! div:nth(3) styles are location dependent*/ } .announcecategory { display : inline-block; /*...*/ /*we can reuse this category style wherever*/ }

Limitaciones y desventajas de OOCSS:

1. Las clases de utilidad vinculan su marcado a la presentación.
2. OOCSS no da reglas de construcción clara y firme, y el tiempo pasado para factorizar la apariencia puede muy a menudo exceder la ganancia de la reutilización. Eso podría aumentar considerablemente el tiempo de realización de los proyectos.

Recomiendo y aconsejo mucho al lector, la charla de Nicole Sullivan: Nuestras mejores prácticas nos están matando , publicada en 2011. Ha permitido a varios integradores comprender mejor OOCSS y comenzar a utilizar este concepto de nomenclatura.

El lector que desee profundizar leerá la wiki del framework OOCSS .

Si alguna vez ha trabajado con Bootstrap, probablemente haya notado al leer esta sección que el equipo de Bootstrap utiliza mucho este enfoque.

existe otras buenas prácticas de naming.

BEM

BEM son las siglas de Block, Element, Modifier y toda la metodología del naming se sostiene en estas tres palabras. ¿La fuerza del concepto? Lo que compone una página o una aplicación web siempre se puede almacenar en una arborescencia de bloques, elementos y modificadores.

Un bloque es una entidad independiente que debe poder moverse sin afectar su apariencia o su funcionamiento.

Un elemento es una parte de un bloque. El contexto de un elemento es el del bloque. Puede ser un encabezado, un pie de página, un contenedor (artículos, secciones...), un menú o incluso un botón. Como parece claramente, un bloque también puede contener otros bloques. Una interfaz puede incluir varias instancias del mismo bloque.

Un modificador es una propiedad que se usa para crear variantes, para hacer cambios mínimos como cambiar colores, tamaño. Existen los modificadores de bloques y los modificadores de elementos.

La metodología BEM tiene tres reglas esenciales:

1. Los bloques y elementos deben tener entre sí un nombre único, que se usará como una clase CSS
2. Los selectores de CSS no tienen que usar los elementos HTML (no del pie de página div)
3. Deben evitarse las cascadas en los selectores de CSS (no de .foo > .bar)
   

 Naming convention:

Bloque político:

• nombre-de-bloque

Elemento:

• nombre-de-bloque__nombre-de-elemento

modificador:

• nombre-bloque--nombre-modificador
• nombre-bloque__nombre-elemento--nombre-modificador

El sitio web oficial se encarga de especificar que solo cuentan los conceptos, quedando libre la sintaxis.

 Advantages of BEM:

• Rendimiento: el rendimiento se refiere más particularmente a la aplicación web. La nomenclatura de BEM permite tener la mayoría de las clases de CSS en el primer nivel. Los navegadores organizan las clases CSS en una tabla del hash global, pero sería demasiado costoso crear subtablas para los descendientes al nivel de cada elemento HTML. Además, en CSS, solo el primer nivel de selección es de alto rendimiento. Cascada de CSS, cuando hay muchos de ellos, esto crea problemas de fluidez, especialmente en las páginas animadas de las aplicaciones Web.
• Responsabilidad: los nombres de las clases son lógicos e intuitivos, y cada miembro del equipo sabe qué hace ese elemento en el sitio web. BEM les da a todos en un proyecto una sintaxis declarativa que pueden compartir. Entonces, están en la misma página.

 Limits and disadvantages of BEM:

• Detallado: La nomenclatura de BEM es un poco detallada. De hecho, notamos que tan pronto como tenemos modificadores para implementar, nos encontramos muy rápidamente con un atributo de clase largo y complejo.

 Important to know:

Conclusión:

Las mejores prácticas son muy importantes porque permiten optimizar nuestro programa en todos los planos (legibilidad del código, mantenibilidad del software, escalabilidad, rapidez de ejecución, ...).