¿Son las constantes de un solo carácter mejores que los literales?

Tautology :

  

Es muy claro si lees la primera oración de la pregunta   que esta pregunta no es sobre usos apropiados como    eliminando números mágicos , se trata de terribles tontos sin sentido    mejor consistencia. Que es a lo que se dirige esta respuesta

El sentido común le dice que const char UPPER_CASE_A = 'A'; o const char A = 'A' no agrega nada más que mantenimiento y complejidad a su sistema. const char STATUS_CODE.ARRIVED = 'A' es un caso diferente.

Constantes representan cosas que son inmutables en tiempo de ejecución, pero es posible que deban modificarse en el futuro en tiempo de compilación. ¿Cuándo const char A = equivale correctamente a algo que no sea A ?

Si ves public static final char COLON = ':' en el código de Java, encuentra a quien escribió eso y rompe sus teclados. Si la representación de COLON cambia alguna vez de : , tendrá una pesadilla de mantenimiento.

Ofuscación:

¿Qué sucede cuando alguien lo cambia a COLON = '-' porque donde lo están utilizando necesita un - en todas partes? ¿Vas a escribir pruebas unitarias que básicamente dicen assertThat(':' == COLON) por cada referencia única de const para asegurarte de que no se cambien? ¿Solo para que alguien arregle la prueba cuando la cambie?

Si alguien realmente argumenta que public static final String EMPTY_STRING = ""; es útil y beneficioso, solo calificaste su conocimiento y lo ignoras de forma segura en todo lo demás.

Tener todos los caracteres imprimibles disponibles con una versión nombrada simplemente demuestra que quien lo hizo, no está calificado para escribir código sin supervisión.

Cohesión:

También reduce artificialmente la cohesión, porque aleja las cosas de las cosas que las usan y están relacionadas con ellas.

  

En programación de computadoras, cohesión se refiere al grado en que la   Los elementos de un módulo pertenecen juntos. Así, la cohesión mide la   Fuerza de relación entre piezas de funcionalidad dentro de un   módulo dado. Por ejemplo, en sistemas altamente cohesivos la funcionalidad es   fuertemente relacionado.

Acoplamiento:

También une muchas clases no relacionadas porque todos terminan haciendo referencia a archivos que no están realmente relacionados con lo que hacen.

  

El acoplamiento apretado es cuando un grupo de clases es altamente dependiente de una   otro. Este escenario surge cuando una clase asume demasiados   responsabilidades, o cuando una preocupación se extiende sobre muchas clases   en lugar de tener su propia clase.

Si usara un mejor nombre como DELIMITER = ',' , todavía tendría el mismo problema, porque el nombre es genérico y no tiene carácter semántico. Reasignar el valor no hace más que ayudar a hacer un análisis de impacto que buscar y reemplazar el literal ',' . ¿Por qué un código lo usa y necesita el , y algún otro código usa pero necesita ; ahora? Todavía tengo que mirar cada uso manualmente y cambiarlos.

En la naturaleza:

Recientemente he refactorizado una aplicación 1,000,000+ LOC que tenía 18 años. Tenía cosas como public static final COMMA = SPACE + "," + SPACE; . Eso no es de ninguna manera mejor que solo insertar " , " donde se necesita.

Si desea argumentar legibilidad , debe aprender a configurar su IDE para que muestre whitespace caracteres donde pueda verlos o lo que sea, eso es solo una razón muy perezosa para introducir entropía en un sistema.

También tenía , definido varias veces con varias faltas de ortografía de la palabra COMMA en varios paquetes y clases. Con referencias a todas las variaciones entremezcladas en código. No fue nada menos que una pesadilla intentar y arreglar algo sin romper algo completamente sin relación.

Igual que con el alfabeto, hubo% UPPER_CASE_A , A , UPPER_A , A_UPPER que la mayor parte del tiempo fueron iguales a A pero en algunos casos no fueron . Para casi todos los personajes, pero no todos los personajes.

Y a partir de las historias de edición, no parece que una sola de ellas haya sido editada o cambiada en los últimos 18 años, debido a lo que debería ser la razón obvia es que rompería demasiadas cosas que no se podían rastrear, por lo que tener nuevos nombres de variables que apunten a lo mismo que nunca se puede cambiar por el mismo motivo.

En ninguna realidad sensata, puedes argumentar que esta práctica no es hacer nada sino comenzar con la máxima entropía.

Refacté todo este lío e incorporé todas las tautologías y las nuevas contrataciones universitarias fueron mucho más productivas porque no tenían que buscar en múltiples niveles de indirección lo que estas const referencias realmente señalaron, porque no estaban confiable en lo que se llamaron vs lo que contenían.

  

El atractivo principal del uso de constantes es que minimizan el mantenimiento cuando se necesita un cambio.

ABSOLUTAMENTE NO. Esta es no la razón para usar constantes porque las constantes no cambian por definición . Si una constante cambia entonces no fue una constante, ¿verdad?

El atractivo de usar constantes no tiene nada que ver con la gestión del cambio y todo lo relacionado con hacer que los programas sean susceptibles de ser escritos, comprendidos y mantenidos por las personas . Si quiero saber en cualquier parte de mi programa donde se utilizan dos puntos como separador de URL, puedo saberlo fácilmente si tengo la disciplina de definir un separador de URL constante, y no puedo saberlo fácilmente si tengo que grep para : y obtenga cada lugar en el código donde se usa : para indicar una clase base, un operador ?: , o lo que sea.

Estoy totalmente en desacuerdo con las otras respuestas que afirman que esto es una pérdida inútil de tiempo. Las constantes nombradas agregan significado a un programa, y tanto los humanos como las máquinas pueden usar esa semántica para comprender un programa más profundamente y mantenerlo de manera más efectiva.

El truco aquí no consiste en evitar las constantes, sino en nombrarlas con sus propiedades semánticas en lugar de sus propiedades sintácticas . ¿Para qué se utiliza la constante? No lo llame Comma a menos que el dominio de negocios de su programa sea tipografía, análisis del idioma inglés o similar. Llámelo ListSeparator o algo por el estilo, para aclarar la semántica de la cosa.

No, eso es tonto.

Lo que es no necesariamente tonto es llevar cosas así a las etiquetas con nombre por razones de localización. Por ejemplo, el delimitador de miles es una coma en América (1,000,000), pero no es una coma en otras configuraciones regionales. Insertar eso en una etiqueta con nombre (con un nombre apropiado, sin comas) le permite al programador ignorar / abstraer esos detalles.

Pero hacer una constante porque "las cuerdas mágicas son malas" es solo un cultivo de carga.

Hay algunos caracteres que pueden ser ambiguos o que se usan para diferentes propósitos. Por ejemplo, usamos '-' como un guión, un signo menos o incluso un guión. Podrías hacer nombres separados como:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '-';
static const wchar_t EM_DASH = '-';

Más tarde, puede elegir modificar su código para desambiguarlo redefiniéndolos como:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '\u2122';
static const wchar_t EM_DASH = '\u2014';

Esa podría ser una razón por la que consideraría definir constantes para ciertos caracteres individuales. Sin embargo , el número de caracteres que son ambiguos de esta manera es pequeño. A lo sumo, parece que lo harías solo por esos. También diría que podrías esperar hasta que realmente tengas la necesidad de distinguir los caracteres ambiguos antes de factorizar el código de esta manera.

Como las convenciones tipográficas pueden variar según el idioma y la región, probablemente sea mejor que cargues esa puntuación ambigua de una tabla de traducción.

Una constante debe agregar significado.

Definir COMMA como una coma no agrega significado, porque sabemos que una coma es una coma. En su lugar, destruimos el significado, porque ahora COMMA en realidad ya no puede ser una coma.

Si usa una coma para un propósito y desea usar una constante nombrada, nombrela según su propósito. Ejemplo:

• city + CharacterClass.COMMA + state = malo
• city + CITY_STATE_DELIMITER + state = bueno

Usar funciones para formatear

Personalmente prefiero FormatCityState(city, state) y no me importa cómo se ve el cuerpo de esa función siempre que sea breve y pase los casos de prueba.

La idea de que una COMMA constante es mejor que ',' o "," es bastante fácil de refutar. Claro que hay casos en los que tiene sentido, por ejemplo, hacer que final String QUOTE = "\""; ahorra mucho en la legibilidad sin todas las barras diagonales, pero salvo los caracteres de control de idioma como \ ' y " no los he encontrado muy útil.

¡Usar final String COMMA = "," no solo es una mala forma, es peligroso! Cuando alguien quiere cambiar el separador de "," a ";" , puede cambiar el archivo de constantes a COMMA = ";" porque es más rápido que lo hagan y simplemente funciona. Excepto, ya sabes, todas las otras cosas que usaron COMMA ahora también son puntos y coma, incluidas las cosas enviadas a consumidores externos. Por lo tanto, pasa todas sus pruebas (porque todo el código de clasificación y no malvado también usaba COMMA) pero las pruebas externas fallarán.

Lo que es útil es darles nombres útiles. Y sí, a veces las constantes múltiples tendrán los mismos contenidos pero nombres diferentes. Por ejemplo, final String LIST_SEPARATOR = "," .

Entonces, tu pregunta es "son las constantes de caracteres individuales mejor que los literales" y la respuesta es inequívocamente no, no lo son. Pero incluso mejor que ambos es un nombre de variable de ámbito estrecho que dice explícitamente cuál es su propósito. Claro, gastará algunos bytes adicionales en esas referencias adicionales (suponiendo que no se compilen con usted, lo que probablemente harán), pero en el mantenimiento a largo plazo, que es donde está la mayor parte del costo de una aplicación, Vale la pena el tiempo para hacer.

He hecho algunos trabajos escribiendo lexers y analizadores y utilicé constantes enteras para representar terminales. Las terminales de un solo carácter tienen el código ASCII como su valor numérico por razones de simplicidad, pero el código podría haber sido algo completamente distinto. Por lo tanto, tendría un T_COMMA al que se le asignó el código ASCII para ',' como su valor constante. Sin embargo, también hubo constantes para los no terminales a los que se asignaron números enteros por encima del conjunto ASCII. Al mirar generadores de analizadores como yacc o bison, o analizadores escritos usando estas herramientas, tengo la impresión de que básicamente todos lo hicieron.

Entonces, mientras que, como todos los demás, creo que no tiene sentido definir constantes con el propósito expreso de usar las constantes en lugar de los literales a lo largo de su código, sí creo que hay casos de borde (analizadores, por ejemplo) donde podría encontrar Código plagado de constantes como las que usted describe. Tenga en cuenta que en el caso del analizador, las constantes no solo están ahí para representar literales de caracteres; representan entidades que podrían simplemente suceder ser literales de caracteres.

Puedo pensar en algunos casos más aislados donde podría tener sentido usar constantes en lugar de los literales correspondientes. Por ejemplo, podría definir NEWLINE como el literal '\ n' en un cuadro de Unix, pero '\ r \ n' o '\ n \ r' si está en el cuadro de Windows o Mac. Lo mismo ocurre con los archivos de análisis que representan datos tabulares; puede definir las constantes FIELDSEPARATOR y RECORDSEPARATOR. En estos casos, en realidad está definiendo una constante para representar un carácter que cumple una determinada función. Aún así, si usted fuera un programador novato, tal vez nombraría constante a su separador de campo COMMA, sin darse cuenta de que debería haberlo llamado FIELDSEPARATOR, y para cuando se dio cuenta, el código estaría en producción y usted estaría en la siguiente proyecto, por lo que la constante erróneamente nombrada permanecerá en el código para que alguien más tarde encuentre y sacuda la cabeza.

Finalmente, la práctica que describe podría tiene sentido en algunos casos en los que escribe código para manejar datos codificados en una codificación de caracteres específica, por ejemplo, iso-8859-1, pero espera que la codificación cambie mas tarde. Por supuesto, en ese caso, tendría mucho más sentido utilizar la localización o la codificación y la decodificación de las bibliotecas para manejarlo, pero si por alguna razón no pudiera usar esa biblioteca para manejar los problemas de codificación, utilice las constantes que solo usaría. tener que redefinir en un solo archivo en lugar de literales codificados en su código fuente podría ser una forma de hacerlo.

En cuanto al artículo al que está vinculado: no creo que intente hacer un caso para reemplazar los literales de caracteres con constantes. Creo que está tratando de ilustrar un método para usar interfaces para atraer constantes a otras partes de su base de código. Las constantes de ejemplo utilizadas para ilustrar esto se eligen muy mal, pero no creo que importen de ninguna manera.

Además de todas las respuestas finas aquí, me gustaría agregar para pensar, que la buena programación se trata de proporcionar abstractions apropiadas que se puedan desarrollar solo y quizás otros, sin tener que repetir el mismo código una y otra vez.

Las buenas abstracciones hacen que el código sea fácil de usar por un lado, y fácil de mantener por otro lado.

Estoy totalmente de acuerdo con que DELIMITER=':' en sí mismo es una mala abstracción, y solo mejor que COLON=':' (ya que este último está totalmente empobrecido).

Una buena abstracción que incluya cadenas y separadores incluiría una forma de empaquetar uno o más elementos de contenido individuales en la cadena y descomprimirlos de la cadena empaquetada también, antes que nada, antes de decirle qué es el delimitador. Tal abstracción se incluiría como un concepto, en la mayoría de los idiomas como clase; por ejemplo, para que su uso sea prácticamente autodocumentado, en el que puede buscar todos los lugares donde se usa esta clase y tener confianza de cuál es la intención del programador con respecto al formato de las cadenas empaquetadas en cada caso en el que se usa alguna abstracción.

Una vez que se proporciona dicha abstracción, sería fácil de usar sin tener que consultar cuál es el valor de DELIMITER o COLON , y, al cambiar los detalles de la implementación, generalmente se limitaría a la implementación. Entonces, en resumen, estas constantes deberían ser realmente detalles de implementación ocultos dentro de una abstracción apropiada.

  

El atractivo principal del uso de constantes es que minimizan el mantenimiento cuando se necesita un cambio.

Las buenas abstracciones, que suelen ser composiciones de varias capacidades relacionadas, son mejores para minimizar el mantenimiento. Primero, separan claramente al proveedor de los consumidores. En segundo lugar, ocultan los detalles de la implementación y, en cambio, proporcionan una funcionalidad directamente útil. En tercer lugar, documentan a un alto nivel cuándo y dónde se están utilizando.

La única vez que he visto usar tales constantes de manera efectiva es para hacer coincidir una API o documento existente. He visto símbolos como COMMA usado porque una pieza particular de software estaba directamente conectada a un analizador que usaba COMMA como una etiqueta en un árbol de sintaxis abstracta. También he visto que se utiliza para coincidir con una especificación formal. en las especificaciones formales, a veces verá símbolos como COMMA en lugar de ',' porque quieren ser lo más claros posible.

En ambos casos, el uso de un símbolo con nombre como COMMA ayuda a proporcionar cohesión a un producto de otro modo disjunto. Ese valor a menudo puede superar el costo de las notaciones demasiado detalladas.

Observe que está intentando hacer una lista.

Entonces, refactorízalo como: String makeList(String[] items)

En otras palabras, elimine el factor logic en lugar de data .
Los idiomas pueden ser diferentes en la forma en que representan las listas, pero las comas siempre son comas (eso es una tautología). Entonces, si el idioma cambia, cambiar el carácter de coma no te ayudará, pero esto lo hará.

Si esta fue una clase escrita como parte de una aplicación por tu compañero desarrollador, es casi seguro que es una mala idea. Como ya lo han señalado otros, tiene sentido definir constantes como SEPARATOR = ',' donde puede cambiar el valor y la constante aún tiene sentido, pero mucho menos las constantes cuyo nombre solo describe su valor.

Sin embargo, hay al menos dos casos en los que tiene sentido declarar constantes cuyo nombre describe exactamente su contenido y donde no puede cambiar el valor sin cambiar adecuadamente el nombre de la constante:

• Constantes matemáticas o físicas, p. ej. %código%. Aquí, la función de la constante es actuar como mnemotécnica, ya que el nombre simbólico PI = 3.14159 es mucho más corto y más legible que el valor que representa.
• Listas exhaustivas de símbolos en un analizador o teclas en un teclado. Incluso podría tener sentido tener una lista de constantes con la mayoría o todos los caracteres Unicode y aquí es donde puede caer su caso. Algunos caracteres como PI son obvios y claramente reconocibles. ¿Pero puedes diferenciar fácilmente A y А ? El primero es letra cirílica А , mientras que el último es letra latina A . Son letras diferentes, representadas por diferentes puntos de código Unicode, aunque gráficamente son casi idénticas. Prefiero tener las constantes A y CYRILLIC_CAPITAL_A en mi código que dos caracteres de aspecto casi idéntico. Por supuesto, esto no tiene sentido si sabe que solo trabajará con caracteres ASCII que no contengan cirílico. Del mismo modo: uso el alfabeto latino día a día, así que si estuviera escribiendo un programa que necesitaba un carácter chino, probablemente preferiría usar una constante en lugar de insertar un carácter que no entiendo. Para alguien que usa los caracteres chinos en el día a día, un carácter chino puede ser obvio, pero uno latino puede ser más fácil de representar como una constante nombrada. Entonces, como ves, depende del contexto. Aún así, una biblioteca puede contener constantes simbólicas para todos los caracteres, ya que los autores no pueden saber de antemano cómo se va a utilizar la biblioteca y qué caracteres pueden necesitar constantes para mejorar la legibilidad en una aplicación específica.

Sin embargo, estos casos generalmente son manejados por clases del sistema o bibliotecas de propósitos especiales y su ocurrencia en el código escrito por los desarrolladores de aplicaciones debería ser muy raro a menos que esté trabajando en un proyecto muy especial.

Tal vez.

Las constantes de un solo carácter son relativamente difíciles de distinguir. Por lo tanto, puede ser bastante fácil pasar por alto el hecho de que está agregando un punto en lugar de una coma

city + '.' + state

mientras que es un error relativamente difícil de cometer con

city + Const.PERIOD + state

Dependiendo de su entorno de internacionalización y globalización, la diferencia entre un apóstrofe ASCII y el apóstrofe de apertura y cierre de Windows-1252 (o la comilla doble de ASCII y la cita doble de apertura y cierre de Windows-1252) puede ser significativa y es notoriamente difícil para visualizar mirando el código.

Ahora, presumiblemente, si poner un punto en lugar de una coma fuera un problema funcional significativo por error, tendría una prueba automatizada que encontraría el error tipográfico. Si su software está generando archivos CSV, esperaría que su suite de pruebas descubriera rápidamente que tuvo un período entre la ciudad y el estado. Si se supone que su software se ejecuta para clientes con una variedad de configuraciones de internacionalización, probablemente su conjunto de pruebas se ejecutará en cada entorno y se recuperará si tiene una cotización abierta de Microsoft si quería tener un apóstrofe.

Podría imaginar un proyecto en el que tuviera más sentido optar por un código más detallado que pudiera evitar estos problemas, especialmente cuando tienes un código más antiguo que no tiene un conjunto de pruebas completo, aunque probablemente no codificaría De esta manera en un proyecto de desarrollo de campo verde. Y agregar una constante para cada carácter de puntuación en lugar de solo aquellos que son potencialmente problemáticos en su aplicación en particular es probablemente un exceso excesivo.

  

¿Las constantes de un solo carácter son mejores que las literales?

Hay muchas conflaciones flotando por aquí. Déjame ver si puedo separarlos.

Las constantes proporcionan:

• semántica
• cambio, durante el desarrollo
• indirección

Bajar a un solo nombre de personaje solo afecta la semántica. Un nombre debe ser útil como comentario y claro en el contexto. Debe expresar significado, no el valor. Si puede hacer todo eso con una sola multa de carácter. Si no puede, por favor no.

Un literal y una constante pueden cambiar durante el desarrollo. Esto es lo que trae el problema del número mágico. Las cuerdas también pueden ser números mágicos.

Si existe un significado semántico, y dado que ambos son constantes, entonces si la constante tiene más valor que un literal se reduce a direccionamiento indirecto.

La indirección puede resolver cualquier problema, aparte de una gran indirección.

La indirección puede resolver el problema del número mágico porque le permite decidir el valor de una idea en un solo lugar. Semánticamente, para que valga la pena el nombre debe dejar claro cuál es la idea. El nombre debe ser sobre la idea, no el valor.

La indirección puede ser exagerada. Algunos prefieren buscar y reemplazar literales para hacer sus cambios. Eso está bien siempre y cuando 42 sea claramente el significado de la vida y no se mezcle con 42, el número atómico del molibdeno.

Donde puede hacer distinciones útiles como esa con una sola letra depende en gran medida del contexto. Pero no lo convertiría en un hábito.

Como contrapunto filosófico a la opinión de la mayoría, debo decir que hay algunos de nosotros que apreciamos al poco sofisticado programador campesino francés del siglo XIX y

  

recordó su monótona y eterna lucidez, sus puntos de vista increíblemente sensatos de todo, su colosal satisfacción con los truismos simplemente porque eran ciertos. "¡Confundirlo todo!" gritó Turnbull para sí mismo, "si él está en el asilo, no puede haber nadie afuera".

     

G.K. Chesterton, el balón y la cruz

No hay nada de malo en apreciar la verdad y no hay nada de malo en decir la verdad, especialmente cuando se habla con una computadora.

  

Si mientes a la computadora, te alcanzará

     

Perry Farrar - Germantown, Maryland (de More Programming Pearls)

Pero, en su mayor parte, estoy de acuerdo con la gente que dice que es tonto. Soy demasiado joven para haber aprendido a programar FORTRAN, pero he oído decir que puedes redefinir 'A' = 'Q' y crear todo tipo de criptogramas maravillosos. No estás haciendo esto.

Más allá de los problemas de i18n mencionados anteriormente (que no están redefiniendo el glifo "COMMA", sino que realmente redefinen el glifo de un DECIMAL_POINT). La construcción de citas francesas o citas individuales británicas para transmitir el significado a los humanos está en juego y esas deberían ser variables, no constantes. La constante sería AMERICAN_COMMA := ',' y el comma := AMERICAN_COMMA

Y, si estuviera usando un patrón de construcción para construir una consulta SQL, preferiría ver

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(" ( ")
 .append(val_1)
 .append(",")
 .append(val_2)
 .append(" ); ")

que cualquier otra cosa, pero si fueras a agregar constantes, sería

INSERT_VALUES_START = " ( "
INSERT_VALUES_END = " ) "
INSERT_VALUES_SEPARATOR = " , "
QUERY_TERMINATOR = ";"

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(INSERT_VALUES_START)
 .append(val_1)
 .append(INSERT_VALUES_SEPARATOR)
 .append(val_2)
 .append(INSERT_VALUES_END)
 .append(QUERY_TERMINATOR)

Sin embargo, si alguna vez has visto un programa (o tipo) de otra persona, es posible que observes algunas peculiaridades interesantes. No todos somos mecanógrafos estelares. Muchos de nosotros llegamos tarde a la programación o nos criaron con teclados soviéticos (donde se teclean las teclas) y nos gusta cortar y pegar letras individuales en lugar de tratar de encontrarlas en el teclado y / o confiar en autocompletar

Nada va a autocompletar una cadena, así que si puedo obtener una coma presionando 'con', alt-space, down, down, down, ingrese y obtenga una cotización presionando 'con', alt-space , abajo, abajo, entrar. Yo podría hacer eso.

Otra cosa que recordar acerca de los literales de cadena es la forma en que se compilan. Al menos en Delphi, (que es el único lenguaje que me he obsesionado con la pila), terminará sus literales en la pila de cada función. Por lo tanto, muchos literales = muchos sobrecarga de funciones; "," en function_A no es el mismo bit de memoria que "," en function_B ". Para combatir esto, hay una" cadena de recursos "que puede construirse y enlazarse de lado a lado, y así es como hacen i18n cosas (matar dos pájaros con un arbusto). En Python, todos tus literales de cadena son objetos, y puede que parezca agradable usar utils.constants.COMMA.join(["some","happy","array","strings"]) , pero no es una idea estelar para los puntos que se repiten una y otra vez en esta página.

  

Pero, ¿cuándo vamos a comenzar a usar un símbolo diferente de ',' para representar una coma?

Para localización.

En los países de habla inglesa, el símbolo que separa las partes completas y fraccionarias de un decimal es ".", que llamamos "punto decimal". En muchos otros países, el símbolo es "," y se suele llamar el equivalente de "coma" en el idioma local. De manera similar, cuando los países de habla inglesa usan "," para separar grupos de tres dígitos en números grandes (como 1,000,000 por un millón), los países que usan una coma como punto decimal usan un punto (1,000,000).

Así que hay un caso para hacer constantes DECIMAL_POINT y COMMA si estás haciendo globalización.