
Apuesto a que tienes un estilo en el que escribes CSS, en su mayor parte. Te gustan los 4 espacios, digamos. Siempre tienes un espacio después de los frenillos y los dos puntos. Siempre pones un espacio después de los conjuntos de reglas. Solo coloca una declaración en una línea, y las únicas declaraciones que pueden ser de varias líneas son cuando son bloques grandes como un degradado o una sombra de cuadro separada por comas.
Puede llevar esto un poco más lejos y codificarlo. Quizás tenga una reunión de equipo al respecto y decida cómo desea diseñar el código. Escribe una guía y la pone a disposición de todos los miembros del equipo.
El Manual básico de GitHub contiene “pautas de código” como esta.
El código limpio es importante, dices. Si bien las diferencias de estilo en el código en realidad no importan en el resultado final (la mayoría de nosotros tenemos procesos de compilación que comprimen el código de todos modos), sí es importante para el trabajo diario. Una base de código desordenada e inconsistente es difícil de ver y difícil de razonar. Saltar al código limpio hace que sea más rápido mantenerse en el estado de ánimo correcto y ponerse a trabajar en el problema en cuestión, sin que los ciclos de desperdicio se vean frustrados por el desorden.
Harry Roberts recientemente incluso lo llamó una prueba de fuego para los desarrolladores:
[Tidy code] Parece algo muy superficial de lo que preocuparse, pero en mi opinión, el código ordenado indica algo más importante: supongo que un desarrollador ordenado tiene más atención a los detalles, es más probable que siga el proceso y es más probable que detecte errores. Con razón o sin ella, lo veo como una prueba de fuego para enfoques y actitudes más generales.
Comprobación / advertencia de estilo automatizada
Un paso más allá de simplemente acordar los estándares es que su computadora realmente lo ayude a asegurarse de que lo está haciendo bien.
Apuesto a que esto es algo mucho más común para los programadores de lenguaje JavaScript o del lado del servidor. Por ejemplo, ESLint es muy popular. Lo configura con un montón de reglas basadas en lo que su equipo decide que es una buena sintaxis.
ESLint ejecutándose en Sublime Text a través de SublimeLinter
ESLint va un poco más allá de la verificación de estilo, ya que, por ejemplo, sabe si usas una función o no, o si intentas usar una variable que no está definida. Herramientas como Rubocop para código Ruby son similares. Puede utilizarlos para comprobar el estilo, pero haga más.
La verificación de estilo no tiene por qué suceder en el editor de código en sí. Es bastante útil si lo es, por lo que puede solucionar problemas inmediatamente mientras está escribiendo, pero no tiene por qué ser así. Puede ser más práctico para un equipo grande y tecnológicamente diverso hacer que la verificación de estilo sea parte de la configuración del proceso de ejecución / compilación de la tarea.
Por ejemplo, ESlint se puede integrar en Grunt o Gulp, por lo que cuando se procesan archivos JavaScript, verá un resultado de error:
Entonces, hay varias formas de incorporar la verificación de estilo:
- Dentro de un IDE local
- Como parte de una configuración de ejecución de tareas local
- Como parte de las pruebas automatizadas
- Alguna combinación de estos
Y puedes llevarlo aún más lejos. Por ejemplo, tratar errores de formación de pelusa como fallar en las pruebas y prevenir cosas del flujo de trabajo de git. Como si no pudiera completar una solicitud de fusión hasta que todo pase.
¡Esperar! ¡Estamos hablando de CSS aquí!
Por supuesto. Hasta donde yo sé, stylelint es el gran jugador aquí. David Clark lo escribió todo aquí en Programar Plusel año pasado.
stylelint es muy parecido a ESlint. Puede incorporarlo de la misma manera: como parte de un flujo de trabajo de ejecución de tareas o directamente en su editor de código.
Salida de línea de comando para stylelint.
Ejemplo de stylelint trabajando en el lado Atom.
En este momento estoy usando Sublime Text, y aquí estoy usando stylelint con SublimeLinter, exactamente la misma interfaz de usuario de linter que uso para ESlint:
Probablemente también le irá bien comenzando con una configuración estándar.
¿Qué pasa con las opciones de CSS obstinadas?
Se podría decir que stylelint (y ESlint) no tienen opiniones. Son intencionalmente súper flexibles. Puede incorporar las reglas que desee (o dejar de lado las reglas), e incluso cuando agrega reglas, están diseñadas para ser flexibles, ya sea haciendo cumplir la regla de una forma u otra e incluso permitiendo excepciones.
Más importante aún, los llamaría no opinados porque no están exactamente juzgando su código. Pero, ¿qué pasa si desea una herramienta para emitir un juicio sobre su código?
“¡Oye, estás usando demasiados flotadores!”
“¡Oye, esa propiedad no está particularmente bien respaldada!”
“¡Oye, @import es bastante malo para el rendimiento!”
Eso es más como territorio CSSLint, que tiene una variedad de reglas bastante obstinadas.
Reglas de ejemplo de CSS Lint, como no permitir ID y no permitir demasiadas fuentes web.
Seguro que hay algún cruce. CSSLint, por ejemplo, puede buscar propiedades duplicadas al igual que stylelint.
¿Puedes usarlos juntos? Probablemente. Ciertamente, en el nivel de línea de comando / corredor de tareas puede hacerlo. No estoy del todo seguro de cómo funcionaría integrarlos a ambos en un linter IDE al mismo tiempo. ¡Intentalo!
Quizás una comparación sea útil para resumir esta parte:
- stylelint se parece mucho a ESlint (menos obstinado)
- CSSLint es muy parecido a JSlint (más obstinado)
¿No se pueden automatizar realmente estas cosas? ¿Cómo solucionar los problemas por mí?
Esto es lo que me hizo pensar en estas cosas en primer lugar. Me gusta bastante el deshilachado a nivel IDE, pero creo que me gusta aún más la idea de la corrección automática de estilo.
Básicamente, estamos hablando de “embellecer” aquí (también conocido como “ordenar código” o “embellecer”).
El nuevo chico súper popular en el bloque para JavaScript es Prettier, que yo diría que es una buena opción. Pero eso no nos ayuda con CSS.
Hay otro, JS Beautifier, que funciona con CSS (¡y HTML!)
Ejemplo de opciones CSS para JS Beautify
CSS Comb es otra herramienta en este callejón. Tiene muchas menos opciones que stylelint (su llamada si eso es bueno o malo), y tiene un generador de configuraciones genial para establecer esas reglas. CSS Comb parece bastante popular y está bien hecho, pero no lo voy a recomendar más, ya que parece que se han alejado del proyecto:
La herramienta ya no se está desarrollando, aunque aún podemos corregir errores de análisis y errores críticos. Eso significa que no debe esperar nuevas funciones u opciones.
CSS está cambiando bastante rápido en estos días, por lo que me pondría nervioso incorporar una herramienta que no se cambiará. Es una especie de fastidio, porque CSS Comb puede hacer algunas cosas que otros no pueden, como reordenar las propiedades como las quiere, lo cual es bastante bueno (aunque como siempre, hay opciones).
Puede que haya una mejor opción que estas dos …
stylefmt
Dado que la mejor opción para la verificación de estilo CSS es stylelint, ¿por qué no usar la configuración exacta de stylelint para corregir el CSS? (Bueno, casi exacto).
Eso es lo que hace stylefmt. Y, como la mayoría de estas otras herramientas de las que hemos hablado, se puede integrar en el nivel de IDE bajo demanda o como parte de los ejecutores de tareas / procesos de compilación.
Aquí hay un ejemplo de mí en Sublime Text con un archivo SCSS que tiene errores de stylelint y se corrigen con stylefmt:
Niiice.
stylefmt no es la única opción, también hay perfeccionista.
Para concluir
La comprobación de estilo es genial. No solo se puede hacer, también se puede personalizar a tu gusto. Puede incorporarse en cualquier lugar de su proceso que funcione mejor para usted y su equipo. Para CSS, te irá bien con stylelint. Incluso puede solucionar problemas automáticamente con herramientas como stylefmt. También puede obtener una cobertura bastante buena en todo su código base, con cosas como ESlint para JavaScript y Rubocop para Ruby.