En C #, int
et Int32
c'est la même chose, mais j'ai lu un certain nombre de fois ce qui int
est préféré Int32
à aucune raison donnée. Y a-t-il une raison et dois-je m'en soucier?
c#
variable-types
Graham
la source
la source
System.Int32
)When something can be read without effort, great effort has gone into its writing.
Easy writing is hard reading
Réponses:
ECMA-334 : 2006 Spécification du langage C # (p18):
la source
Les deux sont en effet synonymes;
int
sera un peu plus familier,Int32
rend les 32 bits plus explicites pour ceux qui lisent votre code. Je serais enclin à utiliserint
où j'ai juste besoin d'un `` entier '',Int32
où la taille est importante (code cryptographique, structures) afin que les futurs responsables sachent qu'il est sûr d'agrandir unint
si approprié, mais je devrais prendre soin de changerInt32
s de la même manière.Le code résultant sera identique: la différence est purement liée à la lisibilité ou à l'apparence du code.
la source
Ils déclarent tous deux des entiers 32 bits et, comme d'autres affiches l'ont indiqué, 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 permet pas ceci:
mais cela permettra:
Allez comprendre.
la source
enum
à utiliserint
n'est pas underive
, mais spécifier ununderlying type
; voir msdn.microsoft.com/en-us/library/sbbt4032.aspx#code-snippet-2J'utilise toujours les types de systèmes - par exemple,
Int32
au lieu deint
. J'ai adopté cette pratique après avoir lu la programmation Applied .NET Framework - l'auteur Jeffrey Richter est un bon argument pour l'utilisation des noms de type complets. Voici les deux points qui m'ont marqué:Les noms de type peuvent varier entre les langages .NET. Par exemple, en C #,
long
mappe vers System.Int64 tandis qu'en C ++ avec des extensions gérées,long
mappe vers Int32. Étant donné que les langues peuvent être mélangées et mises en correspondance 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.De nombreuses méthodes de framework ont des noms de type dans le cadre de leurs noms de méthode:
la source
List<Tuple<Int32, Boolean>> test = new
, Visual Studio va maintenant insérerList<Tuple<int, bool>>()
. Connaissez-vous un moyen de modifier ces compléments automatiques?var
autant que possible pour réduire la verbosité du code. Dans les endroits occasionnels où la saisie semi-automatique entre et crache sur mon sol, je m'ajuste manuellement - c'est littéralement une seconde ou deux de mon temps.int est un mot clé C # et n'est pas ambigu.
La plupart du temps, cela n'a pas d'importance, mais deux choses vont à l'encontre d'Int32:
la source
Comme déjà indiqué,
int
=Int32
. Pour être sûr, assurez-vous de toujours utiliserint.MinValue
/int.MaxValue
lors de l'implémentation de tout ce qui concerne les limites des types de données. Supposons que .NET ait décidé que ceint
serait désormais le casInt64
, votre code serait moins dépendant des limites.la source
int
64 bits, ce serait comme un changement de rupture que je ne crois pas qu'il soit possible (ou certainement sensible) au code défensivement contre de telles éventualités.La taille des octets pour les types n'est pas trop intéressante lorsque vous n'avez à gérer qu'une seule langue (et pour le code que vous n'avez pas à vous rappeler des débordements mathématiques). La partie qui devient intéressante est lorsque vous faites le pont entre une langue et une autre, un objet C # vers COM, etc., ou que vous effectuez un changement de bit ou un masquage et que vous devez vous rappeler (et à vos co-wokers de révision de code) de la taille des données.
Dans la pratique, j'utilise habituellement Int32 juste pour me rappeler de quelle taille ils sont parce que j'écris du C ++ managé (pour faire le pont vers C # par exemple) ainsi que du C ++ non managé / natif.
Tant que vous le savez probablement, en C # est de 64 bits, mais en C ++ natif, il se termine en 32 bits, ou char est unicode / 16 bits tandis qu'en C ++, il est de 8 bits. Mais comment savons-nous cela? La réponse est, parce que nous l'avons recherchée dans le manuel et elle l'a dit.
Avec le temps et les expériences, vous commencerez à être plus attentif aux types lorsque vous écrivez des codes pour faire le pont entre C # et d'autres langages (certains lecteurs ici pensent "pourquoi le feriez-vous?"), Mais à mon humble avis, c'est une meilleure pratique parce que Je ne me souviens pas 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 32 bits").
En F # (même si je ne l'ai jamais utilisé), ils définissent int , int32 et nativeint . La même question devrait se poser, "laquelle dois-je utiliser?". 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 supprimer les ambiguïtés.
Je suppose que cela dépendrait simplement des applications que vous codez, de qui l'utilise, des pratiques de codage que vous et votre équipe suivez, etc. pour justifier quand utiliser Int32.
la source
Il n'y a pas de différence entre
int
etInt32
, mais commeint
c'est un mot-clé de langue, beaucoup de gens le préfèrent stylistiquement (comme avecstring
vsString
).la source
D'après mon expérience, cela a été une convention. Je ne connais aucune raison technique d'utiliser int sur Int32, mais c'est:
J'aime particulièrement ce dernier. :)
la source
J'utilise toujours les types alias (int, chaîne, etc.) lors de la définition d'une variable et utilise le vrai nom lors de l'accès à une méthode statique:
Il semble juste moche de voir quelque chose comme int.TryParse (). Il n'y a pas d'autre raison que le style.
la source
Je sais que la meilleure pratique consiste à utiliser int, et tout le code MSDN utilise int. Cependant, il n'y a pas de raison autre que la normalisation et la cohérence à ma connaissance.
la source
Bien qu'ils soient (pour la plupart) identiques (voir ci-dessous pour la seule différence [bug]), vous devez certainement vous en soucier et vous devez utiliser Int32.
Le nom d'un entier 16 bits est Int16. Pour un entier 64 bits, c'est Int64, et pour un entier 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 banales soient-elles, distraient, conduisent à la confusion, à la perte de temps, à la discussion, etc. (le fait que cette question existe prouve le fait).
L'utilisation d'Int32 permet au développeur de prendre conscience de son choix de type. Quelle est la taille d'un int? Oh ouais, 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. Quand les gens ne sont pas obligés de reconnaître au moins qu'il existe des alternatives, il devient beaucoup trop facile pour int de devenir "LE type entier".
La classe dans le cadre destinée à interagir avec des entiers 32 bits est nommé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
ouInt32 lMax = Int32.MaxValue
?int n'est pas un mot-clé dans tous les langages .NET.
Bien qu'il existe des arguments pour lesquels il est peu probable qu'il change, int peut ne pas toujours être un Int32.
Les inconvénients sont deux caractères supplémentaires à taper et [bug].
Cela ne compilera pas
Mais cela:
la source
Vous ne devriez pas vous en soucier. Vous devriez utiliser la
int
plupart du temps. Cela aidera le portage de votre programme vers une architecture plus large à l'avenir (c'est actuellementint
un aliasSystem.Int32
mais cela pourrait changer). Ce n'est que lorsque la largeur de bits de la variable importe (par exemple: pour contrôler la disposition en mémoire de astruct
) que vous devez utiliserint32
et d'autres (avec le "using System;
" associé ).la source
int est le raccourci du langage C # pour System.Int32
Bien que cela signifie que Microsoft pourrait modifier ce mappage, un post sur les discussions de FogCreek a déclaré [source]
"Sur le problème 64 bits - Microsoft travaille en effet sur une version 64 bits du .NET Framework mais je suis quasiment sûr que le mappage ne sera PAS sur 64 bits sur ce système.
Les raisons:
1. La norme C # ECMA dit spécifiquement que int est 32 bits et long est 64 bits.
2. Microsoft a introduit des propriétés et méthodes 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.
Je pense donc qu'il est prudent de dire que tous les types C # intégrés conserveront leur mappage actuel. "
la source
int est le même que System.Int32 et une fois compilé, il se transformera en la même chose en CIL .
Nous utilisons int par convention en C # car C # veut ressembler à C et C ++ (et Java) et c'est ce que nous utilisons là-bas ...
BTW, je finis par utiliser System.Int32 lors de la déclaration des importations de diverses fonctions de l'API Windows. Je ne sais pas si c'est une convention définie ou non, mais cela me rappelle que je vais sur une DLL externe ...
la source
Il était une fois, le type de données int était lié à 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 bits, et lorsque le 64 bits a commencé à devenir populaire, les gens étaient plus soucieux de le rendre compatible avec les anciens logiciels et le 32 bits existait depuis si longtemps que pour la plupart des compilateurs, un int est simplement supposé être de 32 bits.
la source
Je recommanderais d'utiliser StyleCop de Microsoft .
C'est comme FxCop , mais pour des 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 certainement votre code plus agréable.
Vous pouvez l'inclure dans votre processus de génération pour vérifier automatiquement les violations.
la source
int
etInt32
c'est pareil.int
est un alias pourInt32
.la source
using int = System.Int32;
directive pour tous vos fichiers de code source.Vous ne devriez pas vous en soucier. Si la taille est un problème, j'utiliserais octet, court, entier, 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.
la source
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'attribution d'un type et la version de la classe lors de l'utilisation de méthodes statiques et autres:
la source
int
est un alias pourSystem.Int32
, tel que défini dans ce tableau: Tableau des types intégrés (référence C #)la source
J'utilise int dans le cas où Microsoft modifie l'implémentation par défaut d'un entier en une nouvelle version fangled (appelons-la Int32b).
Microsoft peut alors changer l'alias int en Int32b, et je n'ai pas besoin de changer mon code pour profiter de leur nouvelle implémentation entière (et, espérons-le, améliorée).
Il en va de même pour tous les mots-clés de type.
la source
Vous ne devriez pas vous soucier de la plupart des langages de programmation, sauf si vous avez besoin d'écrire des fonctions mathématiques très spécifiques 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 qu'un Int si vous sachez que vous aurez besoin de plus de 32 bits par exemple)
la source
Ça n'a pas d'importance. int est le mot-clé de la langue et Int32 son type de système réel.
Voir aussi ma réponse ici à une question connexe.
la source
L'utilisation d'Int ou d'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 de nombreux problèmes d'exécution.
la source
Certains compilateurs ont des tailles différentes pour int sur différentes plates-formes (non spécifiques à C #)
Certaines normes de codage (MISRA C) exigent que tous les types utilisés soient de taille spécifiée (c'est-à-dire 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 à gérer.
Portable peut ne pas être applicable à C # si vous allez toujours utiliser C # et la spécification C # ne changera jamais à cet égard.
L'ihmo 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 devient parfois plus de 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 si vous allez faire des opérations au niveau du bit.
la source
It is also good to specify prefixes for different type variables
La notation hongroise est aujourd'hui largement déconseillée et la plupart des styles de codage découragent son utilisation. Les conventions internes desL'utilisation du
Int32
type nécessite une référence à l'espace de nomsSystem
ou une qualification complète (System.Int32
). J'ai tendance à le faireint
, car il ne nécessite pas d'importation d'espace de noms, ce qui réduit les risques de collision d'espace de noms dans certains cas. Lorsqu'il est compilé en IL, il n'y a aucune différence entre les deux.la source
Selon la fenêtre immédiate dans Visual Studio 2012, Int32 est int, Int64 est long. Voici la sortie:
la source
Pensez également à Int16. Si vous avez besoin de stocker un nombre entier en mémoire dans votre application et que vous êtes préoccupé par la quantité de mémoire utilisée, vous pouvez opter pour Int16 car il utilise moins de mémoire et a une plage min / max plus petite que Int32 (qui est ce que int est .)
la source
Il y a quelque temps, je travaillais sur un projet avec Microsoft lorsque nous avons eu la visite d'un membre de l'équipe produit Microsoft .NET CLR. Cette personne a codé des exemples et lorsqu'il a défini ses variables, il a utilisé «Int32» vs «int» et «String» vs «string».
Je me souvenais avoir vu ce style dans un autre exemple de code de Microsoft. J'ai donc fait quelques recherches et j'ai découvert que tout le monde dit qu'il n'y a pas de différence entre «Int32» et «int» à l'exception de 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 il le fait lorsque vous utilisez «int». Ne me demandez pas pourquoi parce que je ne sais pas encore.
Exemple:
Cela marche.
Extrait de: notation Int32 vs int
la source