Distintos sistemas interpretan de forma diferente los saltos de línea de los archivos de texto. Hablamos de LF (\n) y CRLF (\r\n). Aunque no suelen ser visibles durante la edición, sus diferencias pueden afectar a la integridad del código, a los sistemas de control de versiones y a la interoperabilidad entre plataformas.

Qué significan LF y CRLF

LF significa “Line Feed”, mientras que CRLF significa “Carriage Return + Line Feed”. Son secuencias de caracteres que indican el final de una línea en un archivo de texto. Su origen se remonta a los tiempos de las máquinas de escribir y los terminales físicos:

• LF (\n, código ASCII 10): avanza una línea hacia abajo.
• CRLF (\r\n, códigos ASCII 13 y 10): vuelve al inicio de la línea y luego baja una línea.

En entornos Unix (Linux, macOS, etc.), se usa LF. En sistemas Windows, por defecto se utiliza CRLF. Esta diferencia se traslada a la forma en que los editores de texto, compiladores, scripts y herramientas de automatización interpretan los archivos.

Por qué esto importa al desarrollar

El sistema operativo no es el único factor. Al trabajar en equipo, especialmente si el equipo usa diferentes sistemas operativos, estas diferencias pueden causar conflictos en los repositorios de código. Veamos algunas situaciones habituales:

• Cambios innecesarios en Git: Si no hay una configuración coherente, al abrir un archivo en Windows y guardarlo, puede que Git detecte cambios en todas las líneas, aunque no se haya modificado nada del contenido. Solo ha cambiado el salto de línea.
• Errores en scripts: Algunos intérpretes (como Bash en entornos Unix) fallan al ejecutar archivos que contienen CRLF. El error típico es “command not found” cuando se invoca un script con saltos de línea incorrectos.
• Problemas en herramientas de integración continua: Sistemas como Jenkins o GitHub Actions pueden ejecutar tareas de compilación o test sobre entornos Linux, por lo que un CRLF mal gestionado puede interrumpir un pipeline sin una razón evidente a primera vista.

Cómo evitar conflictos y normalizar saltos de línea

Hay varias formas de mantener consistencia sin tener que preocuparnos de los detalles cada vez que guardamos o hacemos commit.

1. Configuración del editor
   La mayoría de los editores modernos permiten definir qué salto de línea usar. En VS Code, por ejemplo, podemos establecer "files.eol": "\n" en el archivo de configuración del proyecto para forzar LF. También aparece en la barra inferior del editor donde se ve qué tipo de salto de línea está usando el documento abierto.

2. Ajustes en Git
   Git proporciona la opción core.autocrlf:

   • En Windows: git config --global core.autocrlf true convierte LF a CRLF al hacer checkout, y CRLF a LF al hacer commit.
   • En Linux/macOS: git config --global core.autocrlf input convierte solo al hacer commit. Esto reduce el riesgo de conflictos y mantiene el historial limpio.

3. EditorConfig
   Es un archivo .editorconfig que puede vivir en el repositorio y definir reglas comunes para todos los editores compatibles. Un ejemplo:

   [*]
   end_of_line = lf
   insert_final_newline = true

4. Preprocesadores o linters
   Herramientas como ESLint, Prettier o incluso Husky con lint-staged pueden asegurarse de que los archivos se guarden con el salto de línea adecuado antes de hacer commit.

Conclusión

LF y CRLF son detalles técnicos que tienen un impacto real en el desarrollo, especialmente en proyectos colaborativos que pueden afectarr a la estabilidad de los entornos y al control de versiones.

Adoptar una convención clara, documentarla y apoyarse en herramientas que la hagan cumplir automáticamente es una forma sencilla de evitar errores innecesarios y mejorar la calidad del proyecto. Si trabajamos en equipos distribuidos o multiplataforma, conviene elegir un único estilo (preferiblemente LF por su compatibilidad) y asegurarnos de que todos los miembros del equipo y herramientas lo respetan.