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 ( o ) Sass 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 : { : ; : ; : red; : red; } { : ; : ; : ; : ; : red; : red; } .texte-erreur font-size 15px background-color #ccc border-color color .bloc-erreur width 250px height 250px background-color #000 font-size 17px border-color color 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: () { : red; : red; } { : ; : ; @include erreur-base(); } { : ; : ; : ; : ; @include erreur-base(); } mixin erreur-base border-color color .texte-erreur font-size 15px background-color #ccc .bloc-erreur width 250px height 250px background-color #000 font-size 17px 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, y . OOCSS BEM OOCSS (POO) es un paradigma de programación que se enfoca en crear objetos reutilizables y establecer relaciones entre ellos, a diferencia de que organiza el código en procedimientos (rutinas, subrutinas o funciones). La programación orientada a objetos la programación procedimental 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: La separación de “ ” de “ ” estructura piel La separación de “ ” de “ ” contenedor contenido CONTENT - SKIN : Defina los patrones “ ” repetitivos como “ ” reutilizables visuales pieles Definir los patrones “ ” repetitivos como “ ” reutilizables invisibles estructuras { : inline-block; : ; : center; : nowrap; : middle; : none; : none; : none; : none; : solid transparent; : ; : ; : ; : ; : color ; } /* structure */ .btn display font-weight 400 text-align white-space vertical-align -webkit-user-select -moz-user-select -ms-user-select user-select border 1px padding 0.375rem 0.75rem font-size 1rem line-height 1.5 border-radius 0.25rem transition 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. > { : red; } { : inline-block; } .announcecategory div :nth(3) color /*...*/ /*BAD! div:nth(3) styles are location dependent*/ .announcecategory display /*...*/ /*we can reuse this category style wherever*/ Limitaciones y desventajas de OOCSS: Las clases de utilidad vinculan su marcado a la presentación. 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: , publicada en 2011. Ha permitido a varios integradores comprender mejor OOCSS y comenzar a utilizar este concepto de nomenclatura. Nuestras mejores prácticas nos están matando 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 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. BEM Un es una entidad independiente que debe poder moverse sin afectar su apariencia o su funcionamiento. bloque Un 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. elemento Un 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. modificador La metodología BEM tiene tres reglas esenciales: Los bloques y elementos deben tener entre sí un nombre único, que se usará como una clase CSS Los selectores de CSS no tienen que usar los elementos HTML (no del pie de página div) 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. La convención de nomenclatura está abierta, alguien puede mezclar las dos convenciones enumeradas anteriormente según las necesidades del proyecto o incluso en la creación si alguien puede hacerlo mejor que las convenciones de nombre existentes. 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, ...).
