¿Debo usar int o Int32?

En C #, int e Int32 son la misma cosa, pero he leído varias veces que int es preferible a Int32 sin motivo alguno. ¿Hay alguna razón, y debería importarme?

ECMA-334 : 2006 C # Language Specification (p18):

Cada uno de los tipos predefinidos es una abreviatura de un tipo proporcionado por el sistema. Por ejemplo, la palabra clave int refiere a la estructura System.Int32 . Como cuestión de estilo, se prefiere el uso de la palabra clave sobre el uso del nombre completo del tipo de sistema.

Los dos son de hecho sinónimos; int será un poco más familiar, Int32 hace que los 32 bits sean más explícitos para quienes leen tu código. Me inclinaría a usar int donde solo necesito ‘un entero’, Int32 donde el tamaño es importante (código criptográfico, estructuras) para que los futuros mantenedores sepan que es seguro ampliar un int si es apropiado, pero deben tener cuidado al cambiar Int32 s en de la misma manera.

El código resultante será idéntico: la diferencia es puramente legibilidad o apariencia del código.

Ambos declaran números enteros de 32 bits, y como otros carteles declararon, el que usas es principalmente una cuestión de estilo sintáctico. Sin embargo, no siempre se comportan de la misma manera. Por ejemplo, el comstackdor de C # no permitirá esto:

 public enum MyEnum : Int32 { member1 = 0 } 

pero permitirá esto:

 public enum MyEnum : int { member1 = 0 } 

Imagínate.

Siempre uso los tipos de sistema, por ejemplo, Int32 en lugar de int. Adopté esta práctica después de leer la Progtwigción de .NET Framework aplicada : el autor Jeffrey Richter es un buen ejemplo para usar los nombres completos de los tipos. Aquí están los dos puntos que se quedaron conmigo:

  1. Los nombres de tipos pueden variar entre los lenguajes .NET. Por ejemplo, en C #, long mapas long a System.Int64 mientras que en C ++ con extensiones administradas, mapas long a Int32. Dado que los idiomas se pueden mezclar y combinar al usar .NET, puede estar seguro de que el uso del nombre de clase explícito siempre será más claro, sin importar el idioma preferido del lector.

  2. Muchos métodos de framework tienen nombres de tipos como parte de sus nombres de métodos:

    BinaryReader br = new BinaryReader( /* ... */ );

    float val = br.ReadSingle(); // OK, but it looks a little odd...

    Single val = br.ReadSingle(); // OK, and is easier to read

int es una palabra clave C # y no es ambigua.

La mayoría de las veces no importa, pero hay dos cosas que van en contra de Int32:

  • Necesita tener un “sistema que usa”; statement. usar “int” no requiere ninguna instrucción de uso.
  • Es posible definir su propia clase llamada Int32 (que sería tonto y confuso). int siempre significa int.

Como ya se dijo, int = Int32 . Para estar seguro, asegúrese de usar siempre int.MinValue / int.MaxValue al implementar cualquier cosa que se preocupe por los límites del tipo de datos. Supongamos .NET decidió que int sería ahora Int64 , su código sería menos dependiente de los límites.

No hay diferencia entre int e Int32 , pero como int es una palabra clave de lenguaje, muchas personas lo prefieren estilísticamente (al igual que con string frente a String ).

El tamaño de bytes para los tipos no es demasiado interesante cuando solo tiene que tratar con un solo idioma (y para el código que no tiene que recordarse a sí mismo sobre los desbordamientos matemáticos). La parte que se vuelve interesante es cuando haces un puente entre un idioma, otro C a un objeto COM, etc., o estás haciendo un cambio de bits o enmascaramiento y necesitas recordarte a ti mismo (y a tus compañeros de revisión de códigos) del tamaño de los datos.

En la práctica, generalmente uso Int32 solo para recordarme a mí mismo qué tamaño tienen porque escribo C ++ administrado (para establecer un puente a C # por ejemplo) así como C ++ no administrado / nativo.

Siempre que sepa, en C # es de 64 bits, pero en C ++ nativo, termina en 32 bits, o char es unicode / 16 bits, mientras que en C ++ es de 8 bits. Pero, ¿cómo sabemos esto? La respuesta es, porque lo buscamos en el manual y lo dice.

Con el tiempo y las experiencias, empezarás a ser más escrupuloso cuando escribas códigos para establecer un puente entre C # y otros idiomas (algunos lectores están pensando “¿por qué lo harías?”), Pero en mi humilde opinión, creo que es una mejor práctica porque No puedo recordar lo que he codificado la semana pasada (o no tengo que especificar en mi documento API que “este parámetro es un entero de 32 bits”).

En F # (aunque nunca lo he usado), definen int , int32 y nativeint . La misma pregunta debería surgir, “¿cuál uso?”. Como otros han mencionado, en la mayoría de los casos, no debería importar (debería ser transparente). Pero, por mi parte, elegiría int32 y uint32 solo para eliminar las ambigüedades.

Supongo que solo dependerá de qué aplicaciones está codificando, quién lo está usando, qué prácticas de encoding siguen usted y su equipo, etc. para justificar cuándo usar Int32.

En mi experiencia, ha sido una cosa de la convención. No conozco ninguna razón técnica para usar int sobre Int32, pero es:

  1. Más rápido para escribir.
  2. Más familiar para el desarrollador típico de C #.
  3. Un color diferente en el resaltado de syntax de Visual Studio por defecto.

Me gusta especialmente ese último. 🙂

Sé que la mejor práctica es usar int, y todo el código de MSDN usa int. Sin embargo, hasta donde yo sé, no hay una razón más allá de la estandarización y la coherencia.

Aunque son (en su mayoría) idénticos (ver a continuación la diferencia de uno [error]), definitivamente debes preocuparte y deberías usar Int32.

  • El nombre para un entero de 16 bits es Int16. Para un entero de 64 bits es Int64, y para un entero de 32 bits, la opción más intuitiva es: int o Int32?

  • La cuestión del tamaño de una variable de tipo Int16, Int32 o Int64 es autorreferencial, pero la cuestión del tamaño de una variable de tipo int es una pregunta perfectamente válida y las preguntas, sin importar cuán triviales sean, distraen, conducen confusión, perder el tiempo, dificultar la discusión, etc. (el hecho de que esta pregunta exista demuestra el punto).

  • El uso de Int32 promueve que el desarrollador sea consciente de su elección de tipo. ¿Qué tan grande es una int otra vez? Oh sí, 32. La probabilidad de que el tamaño del tipo realmente se considere es mayor cuando el tamaño está incluido en el nombre. El uso de Int32 también promueve el conocimiento de las otras opciones. Cuando las personas no están obligadas a reconocer al menos que hay alternativas, se vuelve demasiado fácil para que int se convierta en “EL tipo de entero”.

  • La clase dentro del marco destinado a interactuar con enteros de 32 bits se denomina Int32. Una vez más, que es: más intuitivo, menos confuso, carece de una traducción (innecesaria) (no una traducción en el sistema, sino en la mente del desarrollador), etc. int lMax = Int32.MaxValue o Int32 lMax = Int32.MaxValue ?

  • int no es una palabra clave en todos los lenguajes .NET.

  • Aunque hay argumentos por los que es probable que nunca cambie, int puede no ser siempre un Int32.

Los inconvenientes son dos caracteres adicionales para escribir y [error].

Esto no comstackrá

 public enum MyEnum : Int32 { AEnum = 0 } 

Pero esto hará:

 public enum MyEnum : int { AEnum = 0 } 

Siempre utilizo los tipos de alias (int, cadena, etc.) al definir una variable y uso el nombre real al acceder a un método estático:

 int x, y; ... String.Format ("{0}x{1}", x, y); 

Parece feo ver algo como int.TryParse (). No hay otra razón por la que hago esto aparte del estilo.

No deberías preocuparte. Debe usar int mayor parte del tiempo. Ayudará a trasladar su progtwig a una architecture más amplia en el futuro (actualmente int es un alias de System.Int32 pero eso podría cambiar). Solo cuando el ancho de bit de la variable importa (por ejemplo: para controlar el diseño en la memoria de una struct ) debe usar int32 y otros (con el asociado ” using System; “).

int es el atajo del lenguaje C # para System.Int32

Si bien esto significa que Microsoft podría cambiar este mapeo, una publicación en las discusiones de FogCreek indicó [fuente]

“En el tema de 64 bits: Microsoft está trabajando en una versión de 64 bits de .NET Framework, pero estoy bastante seguro de que int no se correlacionará con 64 bits en ese sistema.

Razones:

1. El estándar C # ECMA dice específicamente que int es de 32 bits y long es de 64 bits.

2. Microsoft introdujo propiedades y métodos adicionales en Framework versión 1.1 que devuelven valores largos en lugar de valores int, como Array.GetLongLength además de Array.GetLength.

Así que creo que es seguro decir que todos los tipos de C # incorporados mantendrán su asignación actual “.

int es lo mismo que System.Int32 y cuando se comstack se convertirá en lo mismo en CIL .

Usamos int por convención en C # ya que C # quiere parecer C y C ++ (y Java) y eso es lo que usamos allí …

Por cierto, termino usando System.Int32 cuando declaro las importaciones de varias funciones API de Windows. No estoy seguro de si esta es una convención definida o no, pero me recuerda que voy a una DLL externa …

Érase una vez, el tipo de datos int se vinculó al tamaño de registro de la máquina objective del comstackdor. Entonces, por ejemplo, un comstackdor para un sistema de 16 bits usaría un entero de 16 bits.

Sin embargo, afortunadamente ya no vemos mucho de 16 bits, y cuando 64-bit comenzó a ser popular, la gente estaba más preocupada por hacerla compatible con un software más antiguo y 32-bit había existido por tanto tiempo que para la mayoría de los comstackdores se supone que es 32 bits.

Yo recomendaría usar StyleCop de Microsoft.

Es como FxCop , pero para cuestiones relacionadas con el estilo. La configuración predeterminada coincide con las guías de estilo internas de Microsoft, pero se puede personalizar para su proyecto.

Puede tomar un tiempo acostumbrarse, pero definitivamente hace que tu código sea más agradable.

Puede incluirlo en su proceso de comstackción para verificar automáticamente si hay violaciones.

No hay diferencia en la práctica y con el tiempo adoptarás tu propia convención. Tiendo a usar la palabra clave al asignar un tipo, y la versión de clase cuando uso métodos estáticos y tal:

int total = Int32.Parse (“1009”);

int e Int32 es lo mismo. int es un alias para Int32 .

No deberías preocuparte. Si el tamaño es una preocupación, usaría byte, corto, int, luego largo. La única razón por la que usaría un int mayor que int32 es si necesita un número superior a 2147483647 o inferior a -2147483648.

Aparte de eso, no me importaría, hay muchos otros artículos con los que preocuparse.

int es un alias para System.Int32 , como se define en esta tabla: Tabla de tipos incorporados (Referencia de C #)

Utilizo int en el caso de que Microsoft cambie la implementación predeterminada para un entero a una nueva versión fangled (llamémoslo Int32b).

Microsoft puede cambiar el alias int a Int32b, y no tengo que cambiar ninguno de mis códigos para aprovechar su nueva (y afortunadamente mejorada) implementación entera.

Lo mismo ocurre con cualquiera de las palabras clave de tipo.

No debería importarle en la mayoría de los lenguajes de progtwigción, a menos que necesite escribir funciones matemáticas muy específicas, o un código optimizado para una architecture específica … Solo asegúrese de que el tamaño del tipo sea suficiente para usted (use algo más grande que un Int si sepa que necesitará más de 32 bits, por ejemplo)

No importa. int es la palabra clave del lenguaje e Int32 su tipo de sistema real.

Ver también mi respuesta aquí a una pregunta relacionada.

El uso de Int o Int32 es lo mismo Int es solo azúcar para simplificar el código para el lector.

Utilice la variante Nullable Int? o Int32? cuando trabajas con bases de datos en campos que contienen null. Eso le ahorrará muchos problemas de tiempo de ejecución.

Algunos comstackdores tienen diferentes tamaños para int en diferentes plataformas (no específicos de C #)

Algunos estándares de encoding (MISRA C) requieren que todos los tipos utilizados tengan el tamaño especificado (es decir, Int32 y no int).

También es bueno especificar prefijos para diferentes variables de tipo (por ejemplo, b para el byte de 8 bits, w para la palabra de 16 bits, yl para la palabra larga de 32 bits => Int32 lMyVariable)

Deberías preocuparte porque hace que tu código sea más portátil y más fácil de mantener.

Portátil puede no ser aplicable a C # si siempre va a utilizar C # y la especificación de C # nunca cambiará en este sentido.

El ihmo que se puede mantener siempre será aplicable, porque la persona que mantiene su código puede no estar al tanto de esta especificación de C # particular, y perder un error si la int ocasional se convierte en más de 2147483647.

En un for-loop simple que cuenta, por ejemplo, los meses del año, no le importará, pero cuando usa la variable en un contexto en el que posiblemente podría fluir, debería preocuparse.

También debería importarle si va a hacer operaciones de bits en ello.

El uso del tipo Int32 requiere una referencia de espacio de nombres al System o totalmente calificado ( System.Int32 ). Tiendo hacia int , porque no requiere una importación de espacio de nombre, por lo tanto, reduce la posibilidad de colisión de espacio de nombres en algunos casos. Cuando se comstack en IL, no hay diferencia entre los dos.

De acuerdo con la ventana Inmediato en Visual Studio 2012 Int32 es int, Int64 es largo. Aquí está el resultado:

 sizeof(int) 4 sizeof(Int32) 4 sizeof(Int64) 8 Int32 int base {System.ValueType}: System.ValueType MaxValue: 2147483647 MinValue: -2147483648 Int64 long base {System.ValueType}: System.ValueType MaxValue: 9223372036854775807 MinValue: -9223372036854775808 int int base {System.ValueType}: System.ValueType MaxValue: 2147483647 MinValue: -2147483648 

Considera también Int16. Si necesita almacenar un entero en la memoria de su aplicación y le preocupa la cantidad de memoria utilizada, entonces podría elegir Int16 ya que utiliza menos memoria y tiene un rango min / max más pequeño que Int32 (que es lo que int es .)

Hace un tiempo, estaba trabajando en un proyecto con Microsoft cuando recibí una visita de alguien del equipo de producto Microsoft .NET CLR. Esta persona codificó ejemplos y cuando definió sus variables usó “Int32” frente a “int” y “String” frente a “cadena”.

Recordaba haber visto este estilo en otro código de ejemplo de Microsoft. Entonces, investigué un poco y descubrí que todos dicen que no hay diferencia entre “Int32” e “int” a excepción de la coloración de syntax. De hecho, encontré un montón de material que sugiere que use “Int32” para hacer que su código sea más legible. Entonces, adopté el estilo.

¡El otro día encontré la diferencia! El comstackdor no le permite escribir enum usando “Int32”, pero sí cuando usa “int”. No me preguntes por qué porque aún no lo sé.

Ejemplo:

 public enum MyEnum : Int32 { AEnum = 0 } 

Esto funciona.

 public enum MyEnum : int { AEnum = 0 } 

Tomado de: notación Int32 vs. int