Programar en inglés o en español
Hará unos 5 años que me uní a un equipo de programación para extender las funcionalidades de un CRM.
Uno de los compañeros me espetó:
Aquí programamos en español, si programas en inglés no se entiende nada.
Mi primera reacción fue de rechazo: toda la documentación en internet está en inglés, cualquier proyecto con el que te encuentres estará en inglés, hay multitud de palabras que no son traducibles, etc. Me parecía algo retrógrado.
Pero tras pensarlo detenidamente, tampoco era un idea tan descabellada, escribir código es como escribir en un lenguaje, ¿por qué no escribirlo en el propio?
En este post voy a explicar mi experiencia programando en español, ventajas y desventajas y cómo decido al final el idioma que utilizaré.
Primeros pasos
Lo primero que me pasó cuando empecé a programar en español es que me encontraba con una serie de palabras clave, usadas habitualmente, que necesitaba traducir del inglés:
Una de las más comunes era “Get”:
GetInvoiceById(int invoiceId);
Get está en todas partes y si no quieres que el resultado de tu código sea Spanglish es mejor escoger adecuandamente una traducción.
En mi caso he pasado por varias fases:
BuscarFacturaPorId(int invoiceId); RecuperarFacturaPorId(int invoiceId); ObtenerFacturaPorId(int invoiceId); GenerarFacturaPorId(int invoiceId);
La selección final dependerá del contexto. Me he dado cuenta de que he ido creándome un sistema de pequeñas convenciones que me ayudan a tomar este tipo de decisiones, como una especie de argot propio.
Por ejemplo:
Buscar suena más lejano que obtener o generar, por tanto utilizaré buscar en métodos que salen de la capa de dominio de mi aplicación. La mayoría de métodos de los repositorios son un caso frecuente.
En cambio, ultilizaré obtener cuando esté recuperando objetos o propiedades de una misma clase:
Public class ProveedorCalidad() { Public ReadOnlyListCertificados() { // Código } Public ObtenerCertificadoPorNombre(string nombre) { // Código } }
La traducción de Get es solo el principio. Palabras como WHERE, OK, LIST, ARRAY, HELPER, MANAGER, UPDATE son otros ejemplos con los que tendrás que lidiar.
No todo es traducible
A pesar de todo, siempre me he encontrado métodos que no he podido traducir, como me ha ocurrido esta última semana trabajando en una integración con MailChimp. Muy a mi pesar he tenido que crear métodos en Spanglish:
ListarBatchWebhooksMailChimp(); ProcesarBatchWebhook();
Traducir estas funciones hubiera sido una mala decisión porque en MailChimp a un WebHook no se le llama LlamadaDeRetotno y a un Batch no se le llama Lote u OperaciónMasiva. Precisamente para que sea más inteligible en estos casos tiendo a mezclar ambos idiomas.
Este tipo de situaciones se suelen dar cuando trabajo con librerías o apis de terceros, pero ya es lógico no forzar una traducción para conceptos de terceros, sería algo así como intentar traducir nombres de persona a otro idioma.
En mi opinión, en estos casos es mejor mantener los conceptos en el idioma original.
IntelliSense
Una de las cosas que más me gusta de programar en español es la visualización del IntelliSense de Visual Studio. Puedes diferenciar claramente entre las funciones de tu código y las del framework, entre llamadas propias y las de librerías de terceros.
Está claro que el método extensor BuscarPor() es uno de los míos ;)
Es más difícil leer código que escribirlo
Esta frase de Joel Spolsky explica por qué los programadores preferimos empezar un proyecto de nuevo a coger uno antiguo y seguir trabajando sobre él.
La frase se refiere a la dificultad técnica de entender el código, no a si está escrito en un idioma u otro, pero si el código estuviera escrito en español, quizá la comprensión lectora también sería más fácil.
Y justo esta es una de las mayores ventajas de codificar en el idioma propio, de golpe todo se ve un poco más nítido:
private void ConfigurarControlesComunesAccion() { ParametrizarBuscadorArticulo(); ConfigurarSeccionDatosParaCobro(); ConfigurarSeccionDatosAnaliticos(); ConfigurarSeccionOtrosDatos(); Pagina.BuscarInput(InputPagina.MotivoBaja) .ReemplazaPorCombo(FactoriaCombos.ComboMotivosBaja()); if (EsUnaAccionQueSustituyeAOtra()) ConfigurarBotonesParaPoderRechazarAccionOrigen(); } private void ConfigurarSeccionOtrosDatos() { _seccionDatosAnaliticos.ConfigurarCampanyaAtencionCliente(); ReemplazarMotivoSustitucionPorCombo(); DesactivarControlesOtrosDatos(); }
Una herramienta más
Codificar en un idioma u otro se ha convertido para mí en una herramienta más. ¿.Net Core o .Net Framework?, ¿web clásica o SPA combinada con WebApi ? ¿base de datos sí o no? ¿español o inglés?
Si el equipo es interno y su lengua materna es el español, todos lo van a agradecer y la comprensión lectora será más fácil.
En cambio si el proyecto es una librería/plugin de código abierto para ser utilizada como componente de otras aplicaciones, o cuando preveas que a tu equipo se pueden incorporar programadores internacionales, o incluso si piensas que tu proyecto será el próximo Facebook, mejor codifica en inglés.
Para el resto de casos, mi elección por defecto es el español.