net - ¿Deberías usar identificadores internacionales en Java/C#?

framework design guidelines (10)

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 los editores pobres y las herramientas de análisis y dificultar que algunas personas lean, o es la arrogancia estadounidense el único argumento en contra?

Depende:

¿Cumple su equipo con los estándares existentes que requieren que use ASCII?
¿Su código será reutilizado o leído alguna vez por alguien que no habla su lengua materna?
¿Visualiza un escenario en el que necesite solicitar ayuda en línea y, por lo tanto, no podrá copiar y pegar su muestra de código tal como está?
¿Está seguro de que su conjunto completo de herramientas admite la codificación de código?

Si respondió ''sí'' a cualquiera de los anteriores, permanezca ASCII solamente. De lo contrario, avance bajo su propio riesgo.

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 fallas 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.

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). Lo creas 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).

Entonces digo que te quedes con los personajes de ascii.

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 usted nunca planea necesitar 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 probablemente sea mejor seguir 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 que no esté en inglés, no es necesario traducir todos los nombres y variables de los métodos al inglés.

Si su empresa no habla inglés, y cree que Domain Driven Design tiene algo que ver, entonces hay otro aspecto: ¿Cómo, nosotros, como desarrolladores, usamos el mismo lenguaje de dominio que nuestro negocio sin gastos indirectos de traducción?

Eso no solo significa traducciones entre idiomas, por ejemplo, inglés y noruego, sino también entre diferentes palabras. Deberíamos usar exactamente las mismas palabras que nuestro negocio para nuestras clases y servicios de entidad.

Me ha resultado más fácil simplemente 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.

Me quedaría con los caracteres ASCII porque si alguien en su equipo de desarrollo está utilizando 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 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 obstáculo para usar caracteres que no sean ASCII, aunque probablemente solo muerda en casos poco claros. Los caracteres permitidos se definen 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 de 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 superas los otros requisitos previos , entonces tienes uno adicional (en mi humilde opinión más importante): cuán 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.?

Aquí hay un ejemplo de 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.