[c#] Quelle est la différence entre String et string en C #?



Answers

Juste pour l'exhaustivité, voici une décharge de cerveau d'informations connexes ...

Comme d'autres l'ont noté, string est un alias pour System.String . Ils compilent le même code, donc au moment de l'exécution, il n'y a aucune différence. C'est juste un des alias en C #. La liste complète est:

object:  System.Object
string:  System.String
bool:    System.Boolean
byte:    System.Byte
sbyte:   System.SByte
short:   System.Int16
ushort:  System.UInt16
int:     System.Int32
uint:    System.UInt32
long:    System.Int64
ulong:   System.UInt64
float:   System.Single
double:  System.Double
decimal: System.Decimal
char:    System.Char

En dehors de la string et de l' object , les alias sont tous des types de valeurs. decimal est un type de valeur, mais pas un type primitif dans le CLR. Le seul type primitif qui n'a pas d'alias est System.IntPtr .

Dans la spécification, les alias de type valeur sont appelés "types simples". Les littéraux peuvent être utilisés pour des valeurs constantes de chaque type simple; aucun autre type de valeur n'a de forme littérale disponible. (Comparez ceci avec VB, qui permet les littéraux DateTime , et a un alias pour cela aussi.)

Il existe une circonstance dans laquelle vous devez utiliser les alias: lors de la spécification explicite du type sous-jacent d'une énumération. Par exemple:

public enum Foo : UInt32 {} // Invalid
public enum Bar : uint   {} // Valid

C'est juste une question de la façon dont la spécification définit les déclarations enum - la partie après les deux points doit être la production intégrale , qui est un jeton de sbyte , byte , short , ushort , int , uint , long , ulong , char . .. par opposition à une production de type utilisée par les déclarations de variables par exemple. Cela n'indique aucune autre différence.

Enfin, quand il s'agit de l'utiliser: personnellement, j'utilise les alias partout pour l'implémentation, mais le type CLR pour toutes les API. Peu importe ce que vous utilisez en termes de mise en œuvre - la cohérence entre votre équipe est agréable, mais personne d'autre ne s'en souciera. D'autre part, il est vraiment important que si vous vous référez à un type dans une API, vous le faites de manière neutre. Une méthode appelée ReadInt32 est non ambiguë, tandis qu'une méthode appelée ReadInt nécessite une interprétation. L'appelant pourrait utiliser un langage qui définit un alias int pour Int16 , par exemple. Les concepteurs de framework .NET ont suivi ce modèle, avec de bons exemples dans les BitConverter , BinaryReader et Convert .

Question

Exemple ( notez le cas ):

string s = "Hello world!";
String s = "Hello world!";

Quelles sont les lignes directrices pour l'utilisation de chacun? Et quelles sont les différences ?




Il y a une différence - vous ne pouvez pas utiliser String sans using System; préalablement.




System.String est la classe de chaînes .NET - dans la string C # est un alias pour System.String - donc en cours d'utilisation, ils sont identiques.

Pour ce qui est des lignes directrices, je ne m'embarrasserais pas trop et j'utiliserais ce que vous voudrez - il y a des choses plus importantes dans la vie et le code sera le même de toute façon.

Si vous trouvez des systèmes de construction où il est nécessaire de spécifier la taille des entiers que vous utilisez et donc d'utiliser Int16 , Int32 , UInt16 , UInt32 etc., il peut sembler plus naturel d'utiliser String - et de se déplacer entre différents langues .net il pourrait rendre les choses plus compréhensibles - sinon j'utiliserais string et int.




Contre ce qui semble être une pratique courante parmi les autres programmeurs, je préfère String sur string , juste pour souligner le fait que String est un type de référence, comme Jon Skeet l'a mentionné.




Comme les autres le disent, ils sont pareils. Les règles StyleCop, par défaut, vous obligeront à utiliser une string de string comme une meilleure pratique de style de code C #, sauf lorsque vous référencez des fonctions statiques System.String , telles que String.Format , String.Join , String.Concat , etc ...




There is no difference between the two - string , however, appears to be the preferred option when considering other developers' source code.




Yes, that's no difference between them, just like the bool and Boolean .




String ( System.String ) est une classe de la bibliothèque de classes de base. string (minuscule) est un travail réservé en C # qui est un alias pour System.String. Int32 vs int est une situation similaire à Boolean vs. bool . Ces mots-clés spécifiques au langage C # vous permettent de déclarer des primitives dans un style similaire à C.




C'est une question de convention, vraiment. "chaîne" ressemble plus à un style C / C ++. La convention générale consiste à utiliser les raccourcis que votre langue choisie a fournis (int / Int pour Int32). Cela vaut aussi pour "objet" et "décimal".

Théoriquement, cela pourrait aider à coder le port dans un futur standard 64 bits dans lequel "int" pourrait signifier Int64, mais ce n'est pas le point, et je m'attendrais à ce que tout assistant de mise à niveau change toute référence "int" à "Int32" fais attention.




string et String sont identiques de toutes les façons (sauf les majuscules "S"). Il n'y a aucune implication de performance de toute façon.

La string minuscules est préférée dans la plupart des projets en raison de la coloration syntaxique




La string minuscule est un alias pour System.String . Ils sont identiques en C# .

Il y a un débat pour savoir si vous devriez utiliser les types de systèmes ( System.Int32 , System.String , etc.) ou les C# aliases ( int , string , etc.). Personnellement, je crois que vous devriez utiliser les C# aliases , mais c'est juste ma préférence personnelle.




Nouvelle réponse après 6 ans et 5 mois (procrastination).

While string is a reserved C# keyword that always has a fixed meaning, String is just an ordinary identifier which could refer to anything. Depending on members of the current type, the current namespace and the applied using directives and their placement, String could be a value or a type distinct from global::System.String .

I shall provide two examples where using directives will not help .

First, when String is a value of the current type (or a local variable):

class MySequence<TElement>
{
  public IEnumerable<TElement> String { get; set; }

  void Example()
  {
    var test = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
  }
}

The above will not compile because IEnumerable<> does not have a non-static member called Format , and no extension methods apply. In the above case, it may still be possible to use String in other contexts where a type is the only possibility syntactically. For example String local = "Hi mum!"; could be OK (depending on namespace and using directives).

Worse: Saying String.Concat(someSequence) will likely (depending on using s) go to the Linq extension method Enumerable.Concat . It will not go to the static method string.Concat .

Secondly, when String is another type , nested inside the current type:

class MyPiano
{
  protected class String
  {
  }

  void Example()
  {
    var test1 = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
    String test2 = "Goodbye";
  }
}

Neither statement in the Example method compiles. Here String is always a piano string , MyPiano.String . No member ( static or not) Format exists on it (or is inherited from its base class). And the value "Goodbye" cannot be converted into it.




Venir en retard à la fête: J'utilise les types CLR 100% du temps (enfin, sauf si vous êtes obligé d'utiliser le type C #, mais je ne me souviens plus quand c'était la dernière fois).

J'ai commencé à le faire il y a des années, selon les livres CLR de Ritchie. Il m'a semblé logique que tous les langages CLR doivent être capables de supporter l'ensemble des types CLR, donc utiliser les types CLR vous-même a fourni plus de clarté, et peut-être plus de code "réutilisable".

Maintenant que je le fais depuis des années, c'est une habitude et j'aime la coloration que VS montre pour les types CLR.

Le seul vrai problème est que l'auto-complétion utilise le type C #, donc je finis par re-taper les types générés automatiquement pour spécifier le type CLR à la place.

Aussi, maintenant, quand je vois "int" ou "string", ça me semble vraiment mal, comme si je regardais le code C des années 1970.




La meilleure réponse que j'ai jamais entendu sur l'utilisation des alias de type fournis en C # vient de Jeffrey Richter dans son livre CLR Via C # . Voici ses 3 raisons:

  • J'ai vu un certain nombre de développeurs confus, ne sachant pas si utiliser de la chaîne ou de la chaîne dans leur code. Parce que dans C # la chaîne (un mot-clé) correspond exactement à System.String (un type FCL), il n'y a pas de différence et peut être utilisée.
  • En C #, longues cartes à System.Int64 , mais dans un langage de programmation différent, long pourrait mapper à un Int16 ou Int32 . En fait, C ++ / CLI traite en fait longtemps comme un Int32 . Quelqu'un lisant le code source dans une langue pourrait facilement mal interpréter l'intention du code s'il ou elle avait l'habitude de programmer dans un langage de programmation différent. En fait, la plupart des langues ne traiteront même pas longtemps comme un mot-clé et ne compileront pas le code qui l'utilise.
  • Le FCL a de nombreuses méthodes qui ont des noms de type dans le cadre de leurs noms de méthodes. Par exemple, le type BinaryReader propose des méthodes telles que ReadBoolean , ReadInt32 , ReadSingle , etc., et le type System.Convert propose des méthodes telles que ToBoolean , ToInt32 , ToSingle , etc. Bien qu'il soit légal d'écrire le code suivant, la ligne avec float me semble très anormale, et il n'est pas évident que la ligne soit correcte:
BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // Ok, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

Donc là vous l'avez. Je pense que ce sont tous de très bons points. Cependant, je ne me vois pas utiliser les conseils de Jeffrey dans mon propre code. Peut-être que je suis trop coincé dans mon monde C # mais je finis par essayer de faire ressembler mon code au code du framework.




Cette vidéo YouTube démontre pratiquement comment ils diffèrent.

Mais maintenant, pour une longue réponse textuelle.

Quand nous parlons de .NET il y a deux choses différentes, il y a un .NET et l'autre il y a des langages ( C# , VB.NET etc.) qui utilisent ce framework.

" System.String " alias "String" (capital "S") est un type de données .NET framework tandis que "string" est un type de données C# .

En bref "String" est un alias (la même chose appelée avec des noms différents) de "string". Donc, techniquement, les deux instructions de code ci-dessous donnera la même sortie.

String s = "I am String";

ou

string s = "I am String";

De la même manière, il existe des alias pour d'autres types de données c # comme indiqué ci-dessous: -

objet: System.Object , chaîne: System.String , booléen: System.Boolean , octet: System.Byte , sbyte: System.SByte , court: System.Int16 et ainsi de suite

Maintenant, la question à un million de dollars du point de vue du programmeur Alors quand utiliser "String" et "string"?

La première chose à éviter est de toujours utiliser l'un d'entre eux. Mais du point de vue des meilleures pratiques quand vous faites une déclaration de variable, il est bon d'utiliser "string" (petit "s") et quand vous l'utilisez comme nom de classe, alors "String" (majuscule "S") est préféré.

Dans le code ci-dessous, le côté gauche est une déclaration de variable et il est déclaré en utilisant "chaîne". A droite nous appelons une méthode donc "String" est plus sensible.

string s = String.ToUpper() ;



Links