Los estilos básicos de codificación en equipos multidisciplinarios

Antes

En los equipos de desarrollo siempre a existido un muy básico estilo de codificación impuesto por defecto por cada IDE que adopta el equipo, en el mundo java Eclipse adopta por defecto ciertos criterios, si usar UTF8 o no, si usar salto de linea tipo unix o usar salto de linea y retorno de carro tipo windows. Si hacías una aplicación para windows con java swing y si todo el equipo trabajaba en windows no existía problema alguno.

El problema

El tema cambió cuando todo comenzó a migrar a la web, las aplicaciones java podían contener algún mensaje con caracteres con codificación ISO-8859–1 propia de windows, y si no especificabas bien, en los navegadores podrían mal interpretar la codificación porque el desarrollador frontend coloco en el meta del html codificación UTF-8 y las cosas comienzan a ir mal.

Por otro lado puede que el mismo equipo de desarrollo backend (java, python, php, ruby, etc) comiencen a tener discrepancia sobre que estilo adoptar o simplemente dejen a su IDE (Eclipse, Intellij IDEA, Vim, etc) la decision de adoptar un estilo en particular, UTF para el código, ISO para el html, espacios para identar, y muchas cosas cosas, y no siendo suficiente que cada uno trabaje por su lado con el estándar del propio IDE, o un estándar que a cada uno le parece el mejor, hacen que su ide le de autoformato al código, y a la hora de versionar, nos encontramos con que existe un tal Pepe como autor de todos los cambios, siendo en realidad que no hizo ningún cambio, más que quitar el retorno de carro en el código que desarrollo Luis, y si no es un desarrollador backend, puede ser que un desarrollador frontend abra el mismo proyecto con su ide (Atom, SublimeText, Vim, WebStorm, etc) y modifica no solo el salto de linea, si no que reformatea la codificación y convierte los archivos de ISO-8859-1 y pasa a UTF-8 porque es el estandar de la web, los server que van a producción son unix, por lo tanto el estandar también es UTF-8, pero perdiendo algunos caracteres debido a la transformación.

La solución

La adopción de EditorConfig

Que es EditorConfig?

Es un simple archivo de texto llamado .editorconfig que lo colocas en la raíz de tu proyecto.

Que contiene?

Los estándares básicos para mantener la consistencia en tu proyecto, sobre escribiendo tu configuración por defecto que tenías en tu IDE, para alinear a todos a un mismo estándar, un ejemplo?

*# .editorconfig
# EditorConfig is awesome: EditorConfig.org

# top-most EditorConfig file root = true

# Unix-style newlines with a newline ending every file [*]
end_of_line = lf

# Matches multiple files with brace expansion notation
# Set default charset [*.{js,py}]
charset = utf-8

# 4 space indentation [*.py]
indent_style = space
indent_size = 4

# Tab indentation (no size specified) [Makefile]
indent_style = tab

# Indentation override for all JS under lib directory [lib/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml [{package.json,.travis.yml}]
indent_style = space
indent_size = 2

Es simple, no es una configuración de un IDE en particulas, es un simple archivo en la raíz de tu proyecto, y permite que todos los IDEs entiendan lo mismo.