C# y Java permiten casi cualquier carácter en nombres de clase, nombres de métodos, variables locales, etc. ¿Es una mala práctica usar caracteres que no sean ASCII, probar los límites de editores deficientes y herramientas de análisis y dificultar a algunas personas leer, o es la arrogancia estadounidense el único argumento en contra?¿Debería usar identificadores internacionales en Java/C#?
Me limitaría al inglés, simplemente porque nunca se sabe quién está trabajando en ese código, y porque algunas herramientas de terceros utilizadas en el progreso de compilación/prueba/seguimiento de fallos pueden tener problemas. Escribir äöüß en un teclado no alemán es simplemente un PITA, y simplemente creo que cualquier persona involucrada en el desarrollo de software debe hablar inglés, pero tal vez sea solo mi arrogancia como un hablante de inglés no nativo.
Lo que usted llama "arrogancia estadounidense" no es si su programa usa nombres de variables internacionales o no, es cuando su programa piensa que "Währung" y "Wahrung" son las mismas palabras.
Yo diría que depende completamente de quién esté trabajando en la base de código.
Si tiene un pequeño grupo de desarrolladores que comparten un idioma común y que nunca planea tener la necesidad de que nadie que no hable el idioma trabaje con el código, siga adelante y use los caracteres que desee.
Si necesita tener personas de diferentes culturas e idiomas trabajando en el código, entonces es mejor que se quede con el inglés, ya que es el denominador común para casi todos en el mundo.
Parte del problema es que el lenguaje Java/C# y sus bibliotecas se basan en palabras en inglés como if y toString(). Personalmente, no me gustaría cambiar de idioma que no sea inglés a inglés mientras leo el código.
Sin embargo, si su base de datos, interfaz de usuario, lógica de negocios (incluidas las metáforas) ya están en algún idioma distinto del inglés, no es necesario traducir todos los nombres y variables de los métodos al inglés.
Depende:
Si respondió 'sí' a cualquiera de las anteriores, quédese ASCII solamente. De lo contrario, avance bajo su propio riesgo.
SI pasa de the other prerequisites a continuación, tiene uno adicional (en mi humilde opinión más importante) - ¿Qué tan difícil es el símbolo para escribir.
En mi teclado en-us habitual, la única forma que conozco de escribir la letra ç es mantener presionada la tecla alt, y presionar 0227 en el teclado numérico, o copiar y pegar.
Esto sería un gran obstáculo en el camino de escribir rápidamente. No querrás ralentizar tu codificación con cosas triviales como esta si no estás obligado a hacerlo. Los teclados internacionales pueden aliviar esto, pero ¿qué sucede si tiene que codificar en su computadora portátil que no tiene un teclado internacional, etc.?
Solía trabajar en un equipo de desarrollo que felizmente se limpió el trasero con cualquier convención de nombres (y para el caso, cualquier otra codificación). Créanlo o no, tener que lidiar con las ä's y las ö's en el código fue un factor que contribuyó a que renunciara. Aunque soy finlandés, prefiero escribir el código con la configuración del teclado de los EE. UU. Porque los corchetes y los corchetes son difíciles de escribir en un teclado finlandés (prueba Alt derecha y 7 y 0 para curlies).
Así que digo que se queden con los caracteres ascii.
Si su empresa no habla inglés, y cree que Domain Driven Design tiene algo que ver, entonces hay otro aspecto: ¿cómo, como desarrolladores, utilizamos el mismo lenguaje de dominio que nuestro negocio sin gastos de traducción?
Eso no solo significa traducciones entre idiomas, por ejemplo, inglés y noruego, sino también entre palabras diferentes. Deberíamos usar exactamente las mismas palabras que nuestro negocio para nuestras clases y servicios de entidad.
Me ha resultado más fácil ceder y usar mi lengua materna. Ahora que mi código usa las mismas palabras, es más fácil mantener una conversación con los expertos de mi dominio. Y después de un tiempo te acostumbras, al igual que te acostumbraste a codificar sin notación húngara.
Here's an example donde he usado identificadores que no son ASCII, porque me pareció más legible que reemplazar las letras griegas con sus nombres en inglés. Aunque no tengo θ o φ en mi teclado (me basé en copiar y pegar)
Sin embargo, estas son todas las variables locales. Mantendría los identificadores que no son ASCII fuera de las interfaces públicas.
Lindo punto, no había pensado en eso. –
Me quedaría con los caracteres ASCII porque si alguien en su equipo de desarrollo usa un SDK que solo admite ASCII o si desea hacer código abierto, pueden surgir muchos problemas. Personalmente, no lo haría aunque no esté planeando traer a alguien que no hable el idioma en el proyecto, porque está dirigiendo un negocio y me parece que alguien que dirija un negocio desearía que su negocio se expandiera. , que en este día y edad significa trascender las fronteras nacionales. Mi opinión es que el inglés es el idioma del reino, e incluso si nombra sus variables en un idioma diferente, no tiene ningún sentido utilizar caracteres que no sean ASCII en su programación. Deje que el lenguaje lo maneje si está manejando datos que son UTF8: mi programa de iPhone (que involucra toneladas de datos de usuario entre el teléfono y el servidor) tiene soporte completo UTF8, pero no tiene UTF8 en el código fuente . Parece que abre una gran lata de gusanos casi sin ningún beneficio.
Hay otro problema para usar caracteres que no sean ASCII, aunque es probable que solo muerda en casos poco claros. Los caracteres permitidos son defined en términos de los métodos Character.isJavaIdentifierStart(int) y Character.isJavaIdentifierPart(int), que se definen en términos de Unicode. Sin embargo, la versión exacta de Unicode utilizada depende de la plataforma Java de la versión, como se especifica en la documentación para java.lang.Character.
Dado que las propiedades de los caracteres cambian ligeramente de una versión Unicode a la siguiente, es posible (aunque probablemente muy poco probable) que pueda tener identificadores que sean válidos en una versión de Java pero no en la siguiente.
Si el producto resultante es bueno, el pequeño grupo de personas crecerá; finalmente superando el lenguaje. Si está escribiendo un código incorrecto, está bien usar otro lenguaje común (que también es intrínsecamente cierto). –