Por qué debería usar la sangría de columna para mejorar la legibilidad de su código

Creo que el aspecto más importante de la programación es la legibilidad del código fuente que escribes o mantienes. Esto implica muchas cosas, desde la sintaxis del lenguaje de programación hasta los nombres de las variables, los comentarios y la sangría. Aquí analizo el último de estos, la sangría .

No se trata del tamaño de la sangría o la elección entre pestañas y espacios, o si debería ser necesario en un lenguaje como Python. A muchas personas les gusta usar una longitud máxima de línea para cada línea de código, generalmente 80 o 120 caracteres. Con esta idea, no hay una longitud máxima y, a veces, necesitará usar la barra de desplazamiento horizontal. Pero no se asuste, no es para todo el código, es solo para algunas partes.

Cuatro ejemplos de mejoras usando sangría de código

Primer ejemplo

Eche un vistazo a este código:

La legibilidad no es tan buena y podrías terminar con algo como esto para evitar el desorden:

Y sus siete líneas se han convertido en casi 40 líneas. Esto con solo tres o cuatro propiedades por objeto. Si fueran ocho propiedades, se convertirían en 70 líneas.

La idea de la que estoy hablando es usar algo como esto (lo llamo código "con sangría de columna"):

Segundo ejemplo

No es solo para objetos literales. Se puede utilizar para cualquier fragmento de código que sea un grupo de líneas similares. Este proceso puede ser rápido. Puede copiar la primera línea, pegarla y luego sobrescribir las piezas cambiantes en cada línea.

También se puede usar en JS import . Compare estas dos versiones:

Estas trece importaciones están ordenadas alfabéticamente por ruta. Todos son de la vscarpeta: cinco de vs/basey ocho de vs/platform.

No puede ver eso sin mover los ojos hacia adelante y hacia atrás en cada línea. Hacer esto es molesto. Por supuesto, no necesita hacer estadísticas sobre cómo sus archivos están importando otros. Pero en algún momento leerá este código para ver si importó algo del archivo correcto o si ya se importó un archivo.

Ahora vea cómo se ve cuando el mismo código tiene sangría de columna:

¿No lo hace eso un poco mejor?

Tercer ejemplo

En este ejemplo, tenemos una declaración de método del compilador de TypeScript:

Nuevamente, puede ver la diferencia entre las líneas más fácilmente. Le ayuda a leer las cinco líneas al mismo tiempo, gastando mucho menos esfuerzo. Y, si necesita agregar un parámetro en cada una de estas 5 líneas, puede hacerlo solo una vez, usando el cursor multilínea en casi todos los editores de código.

Cuarto ejemplo

Aquí está el ejemplo final, con el original y la comparación juntos:

Pros :

  • Tu código se ve más limpio.
  • Su código ha mejorado la legibilidad
  • Es posible que pueda reducir la cantidad de líneas en su código

Contras :

  • La opción de formato automático de los editores de código puede interferir con el diseño
  • Al agregar una línea a un bloque de líneas, a veces debe cambiar todas las demás líneas
  • Escribir código puede llevar mucho tiempo

¿Qué herramientas pueden ayudar a lograrlo?

Hice la sangría de esta manera, manualmente, durante algún tiempo. Es aburrido, pero una vez que empiezas a hacerlo, no puedes parar. Miras tu código, todas esas líneas repetidas que podrían tener sangrías de columna para que sean más legibles, y no puedes continuar sin hacerlo. Es adictivo.

Utilizo Visual Studio y Visual Studio Code, así que intenté encontrar una extensión o complemento que me ayudara a lograrlo. No encontré ninguno. Entonces, en noviembre de 2017 comencé a crear mi propia extensión para Visual Studio Code y la llamé Smart Column Indenter.

Publiqué una primera versión utilizable en el mismo mes. Eche un vistazo a cómo funciona:

Hay áreas en las que se podría mejorar la extensión. Actualmente, sólo funciona con *.ts, *.jsy *.jsonarchivos. Creo que también podría ayudar con archivos XML y HTML, como sangrar en columnas los mismos atributos de etiquetas repetidas o etiquetas diferentes que se repiten en un grupo de líneas.

Una vez que se selecciona el código para la sangría de columna, el algoritmo funciona en tres pasos:

  1. Análisis léxico (o tokenización) del código. Instalé el paquete npm de TypeScript como una dependencia y usé la API del compilador para evitar reinventar la rueda aquí.
  2. Ejecute el algoritmo de subsecuencia común más larga (LCS) pasando cada línea de código como una secuencia de tokens. Ésta es la parte difícil. Muchas referencias en Internet hablan de LCS para solo dos secuencias como entrada, que se resuelve fácilmente con programación dinámica . Como normalmente queremos sangrar columnas de más de dos líneas de código, el problema se convierte en encontrar la secuencia común más larga (LCS) de múltiples cadenas. Este es un problema NP-difícil. Como este es un problema genérico, creé un paquete npm separado (multiple-lcs) con una implementación básica para lograrlo. En algunos casos, no es la mejor solución, pero es viable.
  3. Vuelva a escribir el código para aplicar sangría a las columnas de los tokens que aparecen en la LCS. Cada ficha de la LCS se coloca en una nueva columna.

Para algunos tipos de tokens, como cadenas o nombres de variables, el nombre del tipo se usa en lugar del contenido del algoritmo LCS. El resultado es una subsecuencia más grande.

Puse toda la lógica en un paquete npm separado (smart-column-indenter). Si desea crear una extensión o complemento como este para otro IDE basado en JavaScript, puede usar este paquete.

Mi razón inicial para crear esta solución fue la prueba de concepto. Me gustaría saber qué piensan otros programadores sobre mi solución. Si te gustó, aplaude .

Si tiene críticas constructivas o conoce otras herramientas que hacen lo mismo, deje un comentario. Este es un artículo que encontré útil.

Gracias por leer.

Actualización (2018-03-29): después de que se publicó hace unos días, recibí muchos comentarios, la mayoría de ellos son negativos, pero gracias a todos de todos modos, es bueno saber por qué a muchas personas no les gusta eso. Más tarde descubrí que la gente generalmente lo llama "alineación de código", no encontrará nada sobre "sangría de columna", así que si desea buscar más sobre esto, busque "alineación de código" en su lugar. Lo hice y encontré una publicación de blog interesante del Blog de Terence Eden, ya que la mayoría de los comentarios negativos son sobre problemas con las fusiones de VCS, el historial y las diferencias sucias, copiaré su conclusión: “Si nuestras herramientas hacen que la comprensión de esas ideas sea más difícil, son las herramientas las que deben cambiar, no nosotros ".

Actualización (2018–05–03): como si alguien del equipo de GitHub hubiera leído los comentarios negativos sobre la alineación del código aquí, ahora puede ignorar los espacios en blanco en la revisión del código.

Actualización (2018–05–20): si usa Visual Studio (no Code), Shadman Kudchikar creó una extensión similar, puede leer sobre ella aquí o descargarla aquí.

Factoide

Ahora tenemos pantallas de 22 "con una resolución de 1920 x 1080. No hay razón para limitarse a 80 caracteres por línea, aunque es necesario decidir el límite máximo. El origen de este límite de 80 caracteres es: