Se debe utilizar identificadores internacionales en Java/C#?

Question

C# y Java permiten que casi cualquier carácter de clase de los nombres, los nombres de métodos, variables locales, etc..Es una mala práctica para el uso de caracteres no-ASCII, prueba los límites de buenos editores y herramientas de análisis y hacer que sea difícil para algunas personas para leer, o es la arrogancia Estadounidense el único argumento en contra?

Answer 1

Yo me quedaría con el inglés, simplemente porque normalmente nunca se sabe quién está trabajando en ese código, y debido a que algunas herramientas de terceros utilizada en la construcción/evaluación/seguimiento de errores de progreso puede tener problemas.Escribir äöüß en un No-Teclado alemán es simplemente un pan de PITA, y simplemente creo que cualquier persona involucrada en el desarrollo de software debe hablar inglés, pero tal vez eso es sólo mi arrogancia como un no-nativo de habla inglesa.

Lo que usted llama "la arrogancia Estadounidense" no es si o no utiliza el programa internacional de nombres de las variables, es cuando su programa se piensa "Währung" y "Wahrung" son las mismas palabras.

Answer 2

Yo diría que depende enteramente de que está trabajando en el código base.

Si usted tiene un pequeño grupo de desarrolladores que comparten un lenguaje común y que no siempre el plan que necesita a nadie que no hable el idioma para trabajar en el código, a continuación, seguir adelante y utilizar los caracteres que desee.

Si usted necesita tener personas de diferentes culturas y lenguas de trabajo en el código, entonces es probablemente la mejor manera de seguir con el inglés ya que es el denominador común de casi todo el mundo.

Answer 3

Si su negocio son los que no hablan inglés, y usted piensa Dominio Impulsado por el Diseño tiene algo, entonces hay otro aspecto:¿Cómo nosotros, como desarrolladores, utilizar el mismo dominio del lenguaje como nuestro negocio sin ningún tipo de traducción sobrecarga?

Que no significa solamente las traducciones entre idiomas, inglés y noruego, pero también entre diferentes palabras.Debemos utilizar las mismas palabras a medida que nuestro negocio para nuestras clases de entidad y de los servicios.

He encontrado que es más fácil dar en el uso y mi idioma nativo.Ahora que mi código de uso de las mismas palabras, es más fácil tener una conversación con mi expertos en el dominio.Y después de un tiempo te acostumbras a él, justo como usted se acostumbró a código sin notación húngara.

Answer 4

Yo solía trabajar en un equipo de desarrollo que felizmente se limpió el culo con cualquier denominación (y para el caso cualquier otro código) convenios.Lo creas o no, tener que lidiar con ä y ö en el código fue un factor que contribuye a mí dimisión.A pesar de que soy finlandés, prefiero escribir código con NOSOTROS configuración del teclado porque rizado y corchetes son un dolor de cabeza para escribir en un teclado finlandés (prueba alt derecha y 7 y 0 para curlies).

Así que lo digo con el palo de caracteres ascii.

Answer 5

He aquí un ejemplo de los que yo he utilizado no-ASCII identificadores, porque me pareció más fácil de leer que la sustitución de las letras griegas, con sus nombres en inglés.Aunque no tengo θ o φ en mi teclado (que se basó en copiar-y-pegar.)

Sin embargo todas estas son variables locales.Me gustaría mantener a los no-ASCII identificadores de interfaces públicas.

Answer 6

Esto depende de:

• ¿Su equipo se ajusta a ninguna de las normas existentes, que requieren el uso de ASCII?
• Es el código nunca va a ser factible reutilizar o leído por alguien que no habla tu idioma nativo?
• ¿Se imaginan un escenario en el que tendrás que pedir ayuda en línea y por lo tanto no ser capaz de copiar-pegar el código de ejemplo de como es?
• Está usted seguro de que su suite completa de herramientas de apoyo código de codificación?

Si usted contestó " sí " a cualquiera de las anteriores, quedarse sólo en ASCII.Si no, avanzar a su propio riesgo.

Answer 7

SI has pasado los otros requisitos usted entonces tiene uno extra (en mi humilde opinión es más importante, de uno de lo difícil que es el símbolo para el tipo.

En mi regulares en-us teclado, la única manera que conozco de tipo de la letra ç es mantener pulsada la tecla alt, y golpeó 0227 en el teclado numérico, o copiar y pegar.

Esto sería un ENORME obstáculo en el camino de escribir rápidamente.Usted no quiere frenar su codificación abajo con trivial cosas como esta si no forzada.Teclados internacionales pueden aliviar este, pero entonces, ¿qué sucede si usted tiene el código en su computadora portátil que no tiene un teclado internacional, etc?

Answer 8

Parte del problema es que el Java/C# el lenguaje y sus bibliotecas se basan en las palabras en inglés como if y toString().Yo, personalmente, no me gusta cambiar entre idiomas distintos del inglés y de inglés a la vez que de la lectura del código.

Sin embargo, si su base de datos, interfaz de usuario, de la lógica de negocio (incluyendo las metáforas) ya están en algún idioma que no sea inglés, no hay necesidad de traducir todos los nombres de métodos y variables en inglés.

Answer 9

Yo me quedaría con caracteres ASCII, porque si alguien en su equipo de desarrollo es el uso de un SDK que sólo es compatible con ASCII o que quería hacer su código de fuente abierta, muchos de los problemas que podrían surgir.Personalmente, yo no lo haría incluso si usted no está planeando traer a una persona que no habla el idioma en el proyecto, debido a que se ejecuta un negocio y me parece que uno ejecuta un negocio quiere que su negocio se expanda, que en este día y edad significa que trasciende las fronteras nacionales.Mi opinión es que el inglés es el idioma del reino, e incluso si el nombre de las variables en un idioma diferente, hay poco o ningún punto para utilizar todos los caracteres no ASCII en su programación.Deja que el lenguaje de lidiar con ello si usted es el manejo de datos que es UTF8:mi iPhone programa (que implica toneladas de datos de usuario que va entre el teléfono y el servidor) tiene plena UTF8 apoyo, pero no tiene UTF8 en el código fuente.Parece abrir una gran lata de gusanos para casi ningún beneficio.

Answer 10

Hay otro hazzard a la utilización de caracteres no ASCII, aunque probablemente sólo un bocado en ocultar los casos.Los caracteres permitidos son definido en cuanto a los métodos Carácter.isJavaIdentifierStart(int) y Carácter.isJavaIdentifierPart(int), que se definen en términos de Unicode.Sin embargo, la versión exacta de Unicode utiliza depende de la versión de Java de la plataforma, tal como se especifica en la documentación de java.lang.Carácter.

Desde propiedades de carácter cambiar ligeramente de una versión Unicode a la siguiente, es posible (pero probablemente muy poco probable) que podría tener identificadores que son válidos en una versión de Java, pero no en el siguiente.

Answer 11

Como ya se señaló, a menos que los nombres de método en su mayoría coinciden con el idioma, es un poco raro constantemente cambiar de idioma durante la lectura.

Para los idiomas Escandinavos y alemán, que puedo hablar y hablar, así, para el, yo por lo menos recomendar el uso estándar de las sustituciones, es decir.

ä/æ -> ae, ö/ø -> oe, å -> aa, ü -> ue

etc.sólo en caso de que como otros pueden encontrar que es difícil de escribir las cartas originales sin teclado/keymap cambios.Creo que si, de repente, tenía que trabajar con una base de código donde los desarrolladores se utiliza un tercer idioma (por ejemplo, incluyendo el francés ç) y no hacer esto..La conmutación entre más de 2 mapas de teclado para escribir de manera eficiente sería doloroso en mi experiencia.