Devrais-je utiliser int ou Int32

ECMA-334 : Spécification du langage C # 2006 (p18):

Chacun des types prédéfinis est un raccourci pour un type fourni par le système. Par exemple, le mot-clé int fait référence à struct System.Int32 . Par souci de style, l’utilisation du mot-clé est préférable à l’utilisation du nom complet du type de système.

Les deux sont en effet synonymes; int sera un peu plus familier, Int32 rend le 32 bits plus explicite pour ceux qui lisent votre code. Je serais enclin à utiliser int où j’ai juste besoin d’un “entier”, Int32 où la taille est importante (code cryptographique, structures) pour que les futurs responsables sachent qu’il est prudent d’agrandir un int si nécessaire, mais de changer de la même façon.

Le code résultant sera identique: la différence est purement lisible ou apparence de code.

Ils déclarent tous les deux des nombres entiers de 32 bits et, comme d’autres affiches, celui que vous utilisez est principalement une question de style syntaxique. Cependant, ils ne se comportent pas toujours de la même manière. Par exemple, le compilateur C # ne permettra pas cela:

 public enum MyEnum : Int32 { member1 = 0 } 

mais cela permettra cela:

 public enum MyEnum : int { member1 = 0 } 

Allez comprendre.

J’utilise toujours les types de systèmes – par exemple, Int32 au lieu de int. J’ai adopté cette pratique après avoir lu Applied .NET Framework Programming – Jeffrey Richter fait de bons arguments pour utiliser les noms de types complets. Voici les deux points qui sont restés avec moi:

1. Les noms de type peuvent varier entre les langages .NET. Par exemple, en C #, long mappages long à System.Int64 en C ++ avec les extensions gérées, long mappages long à Int32. Comme les langages peuvent être mélangés et appariés lors de l’utilisation de .NET, vous pouvez être sûr que l’utilisation du nom de classe explicite sera toujours plus claire, quelle que soit la langue préférée du lecteur.

2. De nombreuses méthodes d’infrastructure ont des noms de type dans leurs noms de méthode:

   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 est un mot-clé C # et est sans ambiguïté.

La plupart du temps, cela n’a pas d’importance, mais deux choses vont à l’encontre d’Int32:

• Vous devez avoir un “using system”; déclaration. utiliser “int” ne nécessite aucune instruction using.
• Il est possible de définir votre propre classe appelée Int32 (ce qui serait stupide et déroutant). int signifie toujours int.

Comme déjà indiqué, int = Int32 . Pour être sûr, veillez à toujours utiliser int.MinValue / int.MaxValue lorsque vous implémentez tout ce qui concerne les limites du type de données. Supposons que .NET ait décidé que int serait désormais Int64 , votre code serait moins dépendant des limites.

Il n’y a pas de différence entre int et Int32 , mais comme int est un mot clé de langage, beaucoup de personnes le préfèrent stylistiquement (comme avec ssortingng vs Ssortingng ).

La taille en octets pour les types n’est pas très intéressante lorsque vous ne devez gérer qu’une seule langue (et pour le code que vous n’avez pas besoin de vous rappeler sur les dépassements mathématiques). La partie qui devient intéressante est lorsque vous reliez une langue à une autre, un object C # à un object COM, etc., ou que vous effectuez un décalage ou un masquage des bits et que vous devez vous rappeler (et vos codemandeurs) de la taille des données.

En pratique, j’utilise généralement Int32 juste pour me rappeler leur taille car j’écris en C ++ (pour établir un pont vers C # par exemple) ainsi que C ++ natif / non géré.

Comme vous le savez probablement, en C # est en 64 bits, mais en C ++ natif, il se termine en 32 bits, ou bien en unicode / 16 bits et en C ++ en 8 bits. Mais comment soaps-nous cela? La réponse est, parce que nous l’avons examiné dans le manuel et il l’a dit.

Avec le temps et les expériences, vous commencerez à être plus consciencieux quand vous écrivez des codes pour faire le lien entre le C # et d’autres langues (certains lecteurs pensent “pourquoi le voudriez-vous?”) Mais à mon humble avis Je ne me souviens plus de ce que j’ai codé la semaine dernière (ou je n’ai pas besoin de spécifier dans mon document API que “ce paramètre est un entier de 32 bits”).

Dans F # (bien que je ne l’ aie jamais utilisé), ils définissent int , int32 et nativeint . La même question devrait se poser, “lequel est-ce que j’utilise?”. Comme d’autres l’ont mentionné, dans la plupart des cas, cela ne devrait pas avoir d’importance (devrait être transparent). Mais pour ma part, je choisirais int32 et uint32 juste pour éliminer les ambiguïtés.

Je suppose que cela dépendrait uniquement des applications que vous codez, de qui les utilise, des méthodes de codage que vous et votre équipe suivez, etc. pour justifier l’utilisation d’Int32.

D’après mon expérience, cela a été une convention. Je ne suis au courant d’aucune raison technique d’utiliser int sur Int32, mais c’est:

1. Plus rapide à taper
2. Plus familier au développeur C # typique.
3. Une couleur différente dans la coloration syntaxique du studio visuel par défaut.

J’aime particulièrement ce dernier. 🙂

Je sais que la meilleure pratique consiste à utiliser int, et tout le code MSDN utilise int. Cependant, pour autant que je sache, il n’y a pas de raison au-delà de la normalisation et de la cohérence.

Bien qu’ils soient (pour la plupart) identiques (voir ci-dessous la différence [bug]), vous devez absolument vous en préoccuper et vous devez utiliser Int32.

• Le nom d’un entier 16 bits est Int16. Pour un entier de 64 bits, c’est Int64, et pour un entier de 32 bits, le choix intuitif est: int ou Int32?

• La question de la taille d’une variable de type Int16, Int32 ou Int64 est auto-référencée, mais la question de la taille d’une variable de type int est une question parfaitement valide et les questions, aussi sortingviales soient-elles, distraient, conduisent confusion, perte de temps, entrave à la discussion, etc. (le fait que cette question existe prouve le point).

• L’utilisation d’Int32 favorise que le développeur soit conscient de son choix de type. Quelle est la taille d’un int à nouveau? Oh oui, 32. La probabilité que la taille du type soit réellement prise en compte est plus grande lorsque la taille est incluse dans le nom. L’utilisation d’Int32 favorise également la connaissance des autres choix. Lorsque les gens ne sont pas obligés de reconnaître au moins qu’il existe des alternatives, il devient trop facile pour int de devenir “LE type entier”.

• La classe dans la structure destinée à interagir avec les entiers 32 bits est appelée Int32. Encore une fois, ce qui est: plus intuitif, moins déroutant, il manque une traduction (inutile) (pas une traduction dans le système, mais dans l’esprit du développeur), etc. int lMax = Int32.MaxValue ou Int32 lMax = Int32.MaxValue ?

• int n’est pas un mot clé dans tous les langages .NET.

• Bien qu’il y ait des arguments pour lesquels il est peu probable que cela change, int peut ne pas toujours être un Int32.

Les inconvénients sont deux caractères supplémentaires à taper et [bug].

Cela ne comstackra pas

 public enum MyEnum : Int32 { AEnum = 0 } 

Mais cela va:

 public enum MyEnum : int { AEnum = 0 } 

J’utilise toujours les types aliasés (int, ssortingng, etc.) pour définir une variable et utiliser le vrai nom lors de l’access à une méthode statique:

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

Il semble moche de voir quelque chose comme int.TryParse (). Il n’y a aucune autre raison pour laquelle je fais cela autre que le style.

Vous ne devriez pas vous en soucier. Vous devriez utiliser int plupart du temps. Cela aidera le portage de votre programme vers une architecture plus large à l’avenir (actuellement, int est un alias de System.Int32 mais cela pourrait changer). Ce n’est que lorsque la largeur de la variable est importante (par exemple: pour contrôler la mise en page en mémoire d’une struct ) que vous devez utiliser int32 et autres (avec le ” using System; ” associé).

int est le raccourci du langage C # pour System.Int32

Bien que cela signifie que Microsoft pourrait changer cette cartographie, un article sur les discussions de FogCreek a déclaré [source]

“En ce qui concerne le problème 64 bits, Microsoft travaille en effet sur une version 64 bits du .NET Framework, mais je suis certain que int ne sera PAS mappé sur 64 bits sur ce système.

Les raisons:

1. Le standard C # ECMA dit spécifiquement que int est 32 bits et long est 64 bits.

2. Microsoft a introduit des méthodes et des propriétés supplémentaires dans Framework version 1.1 qui renvoient des valeurs longues au lieu de valeurs int, telles que Array.GetLongLength en plus d’Array.GetLength.

Donc, je pense qu’il est prudent de dire que tous les types C # intégrés conserveront leur mappage actuel. “

int est le même que System.Int32 et lorsqu’il est compilé, il se transformera en CIL .

Nous utilisons int par convention en C # puisque C # veut ressembler à C et C ++ (et Java) et c’est ce que nous utilisons là …

BTW, je finis par utiliser System.Int32 lors de la déclaration des importations de diverses fonctions API Windows. Je ne suis pas sûr que ce soit une convention définie ou non, mais cela me rappelle que je vais sur une DLL externe …

Il était une fois que le type de données int était associé à la taille de registre de la machine ciblée par le compilateur. Ainsi, par exemple, un compilateur pour un système 16 bits utiliserait un entier 16 bits.

Cependant, heureusement, nous ne voyons plus beaucoup de 16-bit, et quand 64-bit a commencé à être populaire, les gens étaient plus soucieux de le rendre compatible avec les anciens logiciels et 32-bit est juste supposé être 32 bits.

Je recommande d’utiliser Microsoft StyleCop .

C’est comme FxCop , mais pour les problèmes liés au style. La configuration par défaut correspond aux guides de style internes de Microsoft, mais elle peut être personnalisée pour votre projet.

Cela peut prendre un peu de temps pour s’y habituer, mais cela rend définitivement votre code plus agréable.

Vous pouvez l’inclure dans votre processus de génération pour rechercher automatiquement les violations.

Cela ne fait aucune différence dans la pratique et avec le temps, vous adopterez votre propre convention. J’ai tendance à utiliser le mot-clé lors de l’atsortingbution d’un type et de la version de classe lors de l’utilisation de méthodes statiques, par exemple:

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

int et Int32 sont les mêmes. int est un alias pour Int32 .

Vous ne devriez pas vous en soucier. Si la taille est un problème, j’utiliserais octet, short, int, puis long. La seule raison pour laquelle vous utiliseriez un int supérieur à int32 est si vous avez besoin d’un nombre supérieur à 2147483647 ou inférieur à -2147483648.

A part ça, je m’en fous, il y a plein d’autres choses à se soucier.

int est un alias pour System.Int32 , tel que défini dans ce tableau: Table des types intégrés (référence C #)

J’utilise int dans le cas où Microsoft modifie l’implémentation par défaut d’un entier en une nouvelle version intégrée (appelons-la Int32b).

Microsoft peut alors changer l’alias int en Int32b, et je n’ai besoin de modifier aucun de mes codes pour tirer parti de leur nouvelle implémentation entière (qui, espérons-le, sera améliorée).

Il en va de même pour tous les mots-clés de type.

Vous ne devriez pas vous soucier de la plupart des langages de programmation, sauf si vous devez écrire des fonctions mathématiques très précises ou du code optimisé pour une architecture spécifique … Assurez-vous simplement que la taille du type vous suffit (utilisez quelque chose de plus grand sachez que vous aurez besoin de plus de 32 bits par exemple)

Cela n’a pas d’importance. int est le mot clé de la langue et Int32 son type de système actuel.

Voir aussi ma réponse ici à une question connexe.

L’utilisation de Int ou Int32 est la même. Int est juste du sucre pour simplifier le code pour le lecteur.

Utilisez la variante Nullable Int? ou Int32? lorsque vous travaillez avec des bases de données sur des champs contenant null. Cela vous évitera beaucoup de problèmes d’exécution.

Certains compilateurs ont des tailles différentes pour int sur différentes plates-formes (pas spécifiques à C #)

Certaines normes de codage (MISRA C) exigent que tous les types utilisés aient une taille spécifiée (par exemple, Int32 et non int).

Il est également bon de spécifier des préfixes pour différentes variables de type (par exemple, b pour octet 8 bits, w pour mot 16 bits et l pour mot long 32 bits => Int32 lMyVariable)

Vous devriez vous en soucier car cela rend votre code plus portable et plus facile à entretenir.

Portable peut ne pas être applicable à C # si vous utilisez toujours C # et la spécification C # ne changera jamais à cet égard.

Une maintenance maintenable sera toujours applicable, car la personne qui gère votre code peut ne pas être au courant de cette spécification C # particulière et manquer un bogue si l’intérêt devient occasionnellement supérieur à 2147483647.

Dans une simple boucle for qui compte par exemple les mois de l’année, vous ne vous en souciez pas, mais lorsque vous utilisez la variable dans un contexte où elle pourrait éventuellement s’écouler, vous devriez vous en soucier.

Vous devriez également vous soucier de savoir si vous allez effectuer des opérations sur les bits.

L’utilisation du type Int32 nécessite une référence d’espace de noms à System ou une qualification complète ( System.Int32 ). Je tend vers int , car il ne nécessite pas une importation d’espace de noms, réduisant ainsi le risque de collision d’espace de noms dans certains cas. Lorsqu’il est compilé en IL, il n’y a pas de différence entre les deux.

Selon la fenêtre immédiate de Visual Studio 2012, Int32 est int, Int64 est long. Voici la sortie:

 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 

Considérer également Int16. Si vous avez besoin de stocker un entier en mémoire dans votre application et que vous êtes préoccupé par la quantité de mémoire utilisée, vous pouvez utiliser Int16 car il utilise moins de mémoire et une scope min / max inférieure à Int32 (ce que int est .)

Il y a quelque temps, je travaillais sur un projet avec Microsoft lorsque nous avons rencontré quelqu’un de l’équipe du produit Microsoft .NET CLR. Cette personne a codé des exemples et quand il a défini ses variables, il a utilisé «Int32» contre «int» et «Ssortingng» contre «ssortingng».

Je me souvenais d’avoir vu ce style dans un autre exemple de code de Microsoft. J’ai donc fait des recherches et constaté que tout le monde dit qu’il n’y a pas de différence entre «Int32» et «int», sauf pour la coloration syntaxique. En fait, j’ai trouvé beaucoup de matériel suggérant que vous utilisiez «Int32» pour rendre votre code plus lisible. J’ai donc adopté le style.

L’autre jour, j’ai trouvé une différence! Le compilateur ne vous permet pas de taper enum en utilisant “Int32”, mais c’est le cas lorsque vous utilisez “int”. Ne me demande pas pourquoi parce que je ne le sais pas encore.

Exemple:

 public enum MyEnum : Int32 { AEnum = 0 } 

Cela marche.

 public enum MyEnum : int { AEnum = 0 } 

Tiré de: notation Int32 vs. int