En una ocasión me encontré con un proyecto en el que el responsable había decidido hacer el proyecto en inglés. La cuestión es ¿es ventajoso programar en inglés?. Con programar en inglés me refiero a declarar todos los nombres de las tablas, métodos y ciertas variables totalmente en inglés. A primera vista puede parecer una gran idea. Acostumbrarse a desarrollar en inglés puede facilitarnos a participar en proyectos de software libre que podemos ver en sourceforge, perfeccionar el inglés y quizá en un futuro nuestro proyecto pueda ser desarrollado en el extranjero.
Sin embargo, esas ventajas se volvieron totalmente en contra del proyecto por los siguientes motivos.
- Empleo de términos incorrectos. Aunque sepamos inglés y hayamos estudiado bastantes años, nos podemos encontrar un término asociado a un tipo de negocio que no conozcamos. En ese caso, lo primero que haremos es utilizar un diccionario o utilizar un traductor. Lo más probable es que el término en concreto tenga varios significados y elijas el incorrecto.
- Ampliación el grupo de trabajo. Un problema siempre ha sido la incorporación de personal en un proyecto. Si utilizas términos en ingles perjudicarás en su incorporación ya que puede que no todo el mundo tiene el mismo nivel de ingles. Lo que ocurrirá es que estas personas intentarán escribir en español y finalmente quedará un batiburrillo de conceptos en inglés y español.
- Poca probabilidad de ser un proyecto internacional. Salvo que el proyecto tenga un enfoque internacional, pocas veces he visto que un programa se desarrolle mitad en España y mitad en extranjero. No digo que no haya pues si conozco algún caso, pero en general, los proyectos que tienen proyección de desarrollo en España no pasan fronteras (refiriendonos en el desarrollo)
- Pocas personas hacen software libre. Quizás una de las ideas que tenias era practicar para familiarizarte en proyectos internacionales o participar en proyectos sourceforge. Sin embargo, existe un porcentaje muy pequeño que estén interesados en participar en este tipo de proyecto. Por ello, lo único que has hecho es hacer algo que te divertía pero al grupo quizá no.
Además de estos problemas, creo que tenemos una ventaja también al escribir en Español frente a desarrolladores en Inglés y es poder detectar en un momento que código es nuestro y que código pertenece a una librería externa. Por ejemplo, en algún tutorial escrito en inglés a veces he copiado una función que a su vez hacía referencia a otra pero como esta estaba en inglés no sabía que también la tenía que incluir y luego me daba fallos. Sin embargo, cuando leo un tutorial con funciones en español, al ver la llamada ya sé que eso no pertenece a la librería y debe estar en otro sitio o la debo crear.
Finalmente, también es perjudicial pensar solo en español pues gran parte de documentación técnica está en inglés. En mi opinión hay que saber inglés para entender la documentación técnica pero en el día a día, donde no todo es perfecto, hay que facilitar las cosas.
Yo pertenezco a esa gran masa de "quiero y no puedo": programo "en inglés" pero todos los comentarios están en español.
ResponderEliminarPor lo menos te garantizas que una "internacionalización" de tu software no implique una refactorización pero, lo que es tocar en elo código, habría que tocar...
Nosotros desarrollamos casi completamente en inglés. Hay cosas que sorprenden, como que desaparece el problema de que si tienes estaciones en Linux (UTF-8) y Windows (ISO-8859-1) antes o después se te corrompe algún comentario (aunque especifiques el charset por proyecto, antes o después se te escapa alguno). También viene bien que no canten los nombres de patrones (LegacyClienteAdapter... en fin).
ResponderEliminarEntre lo peor, si no usas exactamente los mismos términos de negocio que el cliente vas a tener problemas para comunicarte.
Idem Bonilla, code in English comentarios en español, a estas alturas de la vida me resulta muy muy raro llamar a un método getNombre() y desde luego daNombre() y ponNombre() me parecen feos de narices.
ResponderEliminarInteresante tema; últimamente siempre que empiezo un desarrollo me planteo si programar en inglés, porque veo ventajas e inconvenientes, y al final acabo haciendo una mezcla bastante chapucera. Tengo que definirme un criterio claro.
ResponderEliminarNacho y Jmarranz no cuentan para la estadística :) que precisamente desarrollan framework para uso internacional.
ResponderEliminarLa problemática incrementa cuanto más grande es el proyecto y más gente trabaja en él.
Yo creo que pasa un poco lo que dice David. Se crea una mezcla extraña en términos ingleses y españoles y por ejemplo la tabla de clientes te la puedes encontrar en el código como (clientes, customers y client), según quien haya hecho que parte.
Ahora bién, por convenio en java si que me gusta utilizar el set y en get y alguna abreviatura... setNombre, setFecha, setId, etc. y sobre todo a la contraseña la llamo password por la ñ.
Pero como dice Nacho, cuando tratas con el cliente acerca la lógica (clientes, facturas, ventas, etc), tener los nombres en español se te hace más claro ya que se tratan los mismos conceptos.
Saludos,
Coño Jorge... pero es que por ejemplo en java sin poner get ni set pues...
ResponderEliminarPor otro lado, no veo que problemas debes tener con el cliente. Dudo mucho que este se ponga a leer el código
Anonimo...
ResponderEliminarEstoy deacuerdo que java sin el set y get se pierde mucho. No digo para nada de quitar set o get. Al contrario, se trata de hacerlo lo más legible posible y si en java se utiliza set y get como parte del convenio o como bean, adelante!.
A lo que me refiero es a la legibilidad del modelo de negocio entre el equipo. Cuando una persona que desconoce participa, si habla con el cliente y le dice que las facturas le aparecen mal, lo primero que buscará es tablas o nombres con referencias a facturas. El cliente no leera el código, pero tu debes encontrar el código a partir de lo que él te diga.
Concluyendo, desarrollar en lo que mejor veais. Esta solo fué una experiencia en la que una idea se volvió en su contra por diferentes motivos. Pero no hay que ser tampoco un talibán de no utilizar los nombres set, get o add para ciertas cosas. Son palabras muy utilizadas en java y facilitan la comprensión.
S2
Al margen de esto, como curiosidad, este año dí clases partículares a un alumno de la UOC (esta Universidad está en Barcelona). El caso es que una de las prácticas que solicitaron era hacer una aplicación utilizando la librería de coleciones que daba el profesor. Pues aquí teneis una muestra de una de las clases (pongo solo las declaraciones):
ResponderEliminarpublic interface Arbre extends Contenidor
{
public Posicio arrel();
public Recorregut fills(Posicio pare);
public boolean esFulla(Posicio pos);
public Posicio afegir(Posicio pare,E elem);
public E reemplacar(Posicio pos, E elem);
public void intercanviar(Posicio pos1, Posicio pos2);
public void esborrar(Posicio pare, Posicio fill);
public Recorregut posicions();
public Recorregut recorregutPreordre();
public Recorregut recorregutPostordre();
public Recorregut recorregutPerNivells();
}
Todo el API era así. Se nos hizo bastante complicado entenderlo al principio.
Es curioso. Has vivido en tus propias carnes el problema del programador chauvinista que usa su lengua nativa sin pensar en la legibilidad para otros, y sin embargo sigues defendiéndolo. ¿O quizá, irónicamente, no ves que es lo mismo con el castellano?
EliminarNo conozco a nadie (hispanohablante) que se haya encontrado un programa hecho por un chino o un alemán, por decir algo, y se haya alegrado por que los comentarios y las variables estuvieran en chino o alemán. Porque claro, es obvio que chinos y alemanes deben escribir en inglés para que YO lo lea, incluso aunque piensen que nunca lo leerá nadie no-chino o no-alemán. Por si acaso. Pero yo escribo en castellano, faltaría más.
Jorge,
ResponderEliminarLa legibilidad del modelo de negocio entre el equipo se consigue con una buena documentación del código. Es mi opinión vaya.
Donde si estoy de acuerdo es que como no haya mucho control y el programador sea un poco "despistado" (por llamarle de algún modo) pues encontrarte con auténticas aberraciones...
caso real: getDataAccion()
inglés, catalán y castellano en el mismo identificador.
A lo largo de hoy he publicado el tema en meneame y he seguido los comentarios:
ResponderEliminarhttp://www.meneame.net/story/programar-espanol-ingles-opinion
La verdad es que me he sorprendido porque la cosa está al 50%. Hay más gente que programa en inglés de lo que pensaba.
S2
Una de las ventajas de hacerlo en inglés es que los nombres tienden a ser más cortos, lo cual ayuda.
ResponderEliminarEn cuanto a la última ventaja que mencionas sobre detectar código que no es tuyo... desde el momento que lo incorporas a tu programa, ese código es tuyo, tu responsabilidad, así que no estoy a favor de tratarlo de forma diferente.
Yo creo que lo más importante es definir un criterio claro y seguirlo, no creo que una de las opciones sea claramente superior a la otra.
Ah y get/set "of course", es un convenio que siempre ayuda, aunque luego sea getCliente().
S!
Douglas:
ResponderEliminarSeria muy importante respetar las convenciones de java, luego decidir si se desea escribir el código en un idioma en particular. Respetando las convenciones se consigue que el código sea inteligible en su mayoría, es decir, si en el grupo de desarrollo se incorpora un nuevo programador este comprendería por definición muchas cosas en el código. También se puede tener un grupo de convenciones de programación en el grupo de desarrollo como regla general.
Estas son algunas direcciones que pueden servir de guía:
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
http://geosoft.no/development/javastyle.html
http://developer.netscape.com/docs/technote/java/codestyle.html
Una ventaja que veo a programar en inglés es que ante la incorporación de un programador extranjero, éste tendrá más facilidad para entender el código.
ResponderEliminarDefinitivamente creo que depende en el tipo de proyecto en el que hayan participado. Que pasa si tienes una base de datos en español? ¿Pasaría todo tu código al inglés? Como bien mencionan existen casos donde los términos no tienen traducción al inglés y es mejor tener el api al español. Por ejemplo, actualmente participo en un proyecto donde existen términos como:
ResponderEliminar- 100 al millar
- Mandamiento de ejecución
- Suerte Principal
Son términos que tanto en la documentación, como en el código y en la base de datos aparecen con nombres similares. Esto ha ayudado mucho al proyecto ya que existen sin exagerar más de 400 tablas y un vocabulario cercano a los 2000 términos como para traducir todo.
Estoy de acuerdo que la nomenclatura en inglés "se ve mejor" o "es más internacional" pero definitivamente hay excepciones.
No sé si aporta algo al debate, pero los lenguajes de programación, independientemente de su lugar de creación, ESTÁN en inglés (la gran mayoría, los "grandes"), y esto nos tiene que sugerir algo: Esta discusión ya la tuvieron antes, y la resolvieron dejando todo en inglés. Es un estándar.
ResponderEliminar