Exemple ( notez le cas ):

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

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

stringest un alias en C # pour System.String.
Donc techniquement, il n'y a pas de différence. C'est comme int contre System.Int32 .

En ce qui concerne les directives, il est généralement recommandé d'utiliser stringchaque fois que vous faites référence à un objet.

par exemple

string place = "world";

De même, je pense qu'il est généralement recommandé d'utiliser Stringsi vous devez vous référer spécifiquement à la classe.

par exemple

string greet = String.Format("Hello {0}!", place);

C'est le style que Microsoft a tendance à utiliser dans ses exemples .

Il semble que les conseils dans ce domaine peuvent avoir changé, car StyleCop impose désormais l'utilisation des alias spécifiques à C #.

Juste pour être complet, voici une décharge de cerveau d'informations connexes ...

Comme d'autres l'ont noté, stringest un alias pour System.String. Ils compilent dans le même code, donc au moment de l'exécution, il n'y a aucune différence. Ce n'est qu'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

Mis à part stringet object, les alias sont tous des types de valeur. decimalest 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 formes littérales disponibles. (Comparez cela avec VB, qui autorise les DateTimelittéraux et a aussi un alias.)

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 les spécifications définit les Déclarations ENUM - la partie après le côlon doit être le type intégré de production, ce qui est un signe de sbyte, byte, short, ushort, int, uint, long, ulong, char... par opposition à un genre production utilisé par les déclarations de variables par exemple. Cela n'indique aucune autre différence.

Enfin, en ce qui concerne l'utilisation: personnellement, j'utilise les alias partout pour l'implémentation, mais le type CLR pour toutes les API. Peu importe vraiment ce que vous utilisez en termes d'implémentation - la cohérence au sein de votre équipe est agréable, mais personne d'autre ne s'en souciera. D'un autre côté, il est vraiment important que si vous vous référez à un type dans une API, vous le faites d'une manière indépendante de la langue. Une méthode appelée ReadInt32n'est pas ambiguë, tandis qu'une méthode appelée ReadIntnécessite une interprétation. L'appelant pourrait utiliser une langue qui définit un intalias pour Int16, par exemple. Les concepteurs du framework .NET ont suivi ce modèle, de bons exemples étant dans les BitConverter, BinaryReaderet les Convertclasses.

Stringreprésente System.Stringet c'est un type .NET Framework. stringest un alias en langage C # pour System.String. Les deux sont compilés System.Stringen IL (Intermediate Language), il n'y a donc pas de différence. Choisissez ce que vous aimez et utilisez-le. Si vous codez en C #, je préfère stringcar c'est un alias de type C # et bien connu des programmeurs C #.

Je peux en dire autant de ( int, System.Int32) etc.

La meilleure réponse que j'ai jamais entendu parler de 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 s'il fallait utiliser chaîne ou une chaîne dans leur code. Parce qu'en C # la chaîne (un mot-clé) correspond exactement à System.String (un type FCL), il n'y a pas de différence et l'une ou l'autre peut être utilisée.
• En C #, les mappages longs vers System.Int64 , mais dans un langage de programmation différent, long peuvent mapper vers un Int16 ou Int32 . En fait, C ++ / CLI traite en fait longtemps comme un Int32 . Quelqu'un qui lit le code source dans une langue pourrait facilement mal interpréter l'intention du code s'il était habitué à programmer dans un autre langage de programmation. 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 possède de nombreuses méthodes dont les noms de type font partie de leurs noms de méthode. Par exemple, le type BinaryReader propose des méthodes telles que ReadBoolean , ReadInt32 , ReadSingle , etc. 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 peu naturelle, 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

Alors voilà. Je pense que ce sont tous de très bons points. Cependant, je ne me retrouve 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 framework.

string est un mot réservé, mais String n'est qu'un nom de classe. Cela signifie qu'il stringne peut pas être utilisé seul comme nom de variable.

Si, pour une raison quelconque, vous vouliez une variable appelée chaîne , vous ne verriez que la première de ces compilations:

StringBuilder String = new StringBuilder();  // compiles
StringBuilder string = new StringBuilder();  // doesn't compile 

Si vous voulez vraiment un nom de variable appelé chaîne, vous pouvez l'utiliser @comme préfixe:

StringBuilder @string = new StringBuilder();

Autre différence critique: Stack Overflow les met en évidence différemment.

Il y a une différence - vous ne pouvez pas utiliser Stringsans using System;au préalable.

Il a été couvert ci-dessus; cependant, vous ne pouvez pas l'utiliser stringen réflexion; vous devez utiliser String.

System.Stringest la classe de chaîne .NET - en C # stringest un alias pourSystem.String - donc à l'usage elles sont les mêmes.

En ce qui concerne les directives, je ne serais pas trop embourbé et j'utiliserais simplement ce que vous ressentez - il y a des choses plus importantes dans la vie et le code sera de toute façon le même.

Si vous trouvez - vous des systèmes de construction où il est nécessaire de préciser la taille des entiers que vous utilisez et ainsi tendance à utiliser Int16, Int32, UInt16, UInt32etc. , alors il peut sembler plus naturel d'utiliser String- et lorsqu'ils se déplacent entre les différentes langues de .net , il pourrait rendre les choses plus compréhensibles - sinon j'utiliserais string et int.

Je préfère les .NETtypes en majuscules (plutôt que les alias) pour des raisons de formatage. Les .NETtypes sont colorés de la même manière que les autres types d'objet (les types de valeur sont des objets appropriés, après tout).

Mots - clés conditionnel et de contrôle (comme if, switch, etreturn ) sont en minuscules et de couleur bleu foncé (par défaut). Et je préfère ne pas avoir le désaccord sur l'utilisation et le format.

Considérer:

String someString; 
string anotherString; 

stringet Stringsont identiques à tous égards (sauf le "S" majuscule). Il n'y a aucune incidence sur les performances dans les deux cas.

Les minuscules stringsont préférées dans la plupart des projets en raison de la coloration syntaxique

C # est un langage utilisé avec le CLR.

string est un type en C #.

System.String est un type du CLR.

Lorsque vous utilisez C # avec le CLR stringsera mappé System.String.

Théoriquement, vous pouvez implémenter un compilateur C # qui génère un bytecode Java. Une mise en œuvre judicieuse de ce compilateur carte probablement stringà java.lang.Stringpour interopérer avec la bibliothèque d'exécution Java.

Cette vidéo YouTube montre pratiquement en quoi ils diffèrent.

Mais maintenant, pour une longue réponse textuelle.

Lorsque nous parlons de .NETdeux choses différentes, l'une est un .NETframework et l'autre il y a des langages ( C#, VB.NETetc.) qui utilisent ce framework.

" System.String" aka "String" (majuscule "S") est un .NETtype de données de framework tandis que "string" est un C#type de données.

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 donneront 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, string: System.String, bool: System.Booleanoctet: System.Byte, sbyte: System.SBytecourt: System.Int16et ainsi de suite

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

Première chose pour éviter la confusion, utilisez l'un d'eux de manière cohérente. Mais du point de vue des meilleures pratiques, lorsque vous faites une déclaration de variable, il est bon d'utiliser "string" (petit "s") et lorsque vous l'utilisez comme nom de classe, "String" (majuscule "S") est préférable.

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

string s = String.ToUpper() ;

Les minuscules stringsont un alias pour System.String. Ils sont les mêmes en C#.

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

stringest juste un alias pour System.String. Le compilateur les traitera de manière identique.

La seule différence pratique est la mise en évidence de la syntaxe comme vous le mentionnez, et que vous devez écrire using Systemsi vous utilisez String.

Les deux sont les même. Mais du point de vue des directives de codage, il est préférable d'utiliser à la stringplace de String. C'est ce que les développeurs utilisent généralement. par exemple, au lieu d'utiliser, Int32nous utilisons inttel intquel alias pourInt32

FYI "La chaîne de mots clés est simplement un alias pour la classe prédéfinie System.String." - Spécification du langage C # 4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

Comme le disent les autres, ce sont les mêmes. Règles StyleCop, par défaut, vous appliquer à utiliser stringcomme une meilleure pratique de style de code C #, sauf en cas de référencement des System.Stringfonctions statiques, tels que String.Format, String.Join, String.Concat, etc ...

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

Tandis que stringest un mot-clé C # réservé qui a toujours une signification fixe, Stringest juste un identifiant ordinaire qui pourrait faire référence à n'importe quoi. Selon les membres du type actuel, l'espace de noms actuel et les usingdirectives appliquées et leur placement Stringpeuvent être une valeur ou un type distinct de global::System.String.

Je fournirai deux exemples où les usingdirectives ne serviront à rien .

Tout d'abord, quand Stringest une valeur du type actuel (ou une variable locale):

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

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

Ce qui précède ne sera pas compilé car IEnumerable<> aucun membre non statique Formatn'est appelé et aucune méthode d'extension ne s'applique. Dans le cas ci-dessus, il peut toujours être possible d'utiliser Stringdans d'autres contextes où un type est la seule possibilité syntaxiquement. Par exemple, String local = "Hi mum!";pourrait être OK (en fonction de l'espace de noms et des usingdirectives).

Pire: dire String.Concat(someSequence) ira probablement (selon les usings) à la méthode d'extension Linq Enumerable.Concat. Il n'ira pas à la méthode statique string.Concat.

Deuxièmement, lorsque String est un autre type , imbriqué dans le type actuel:

class MyPiano
{
  protected class String
  {
  }

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

Aucune instruction de la Exampleméthode ne se compile. Voici Stringtoujours un piano chaîne , MyPiano.String. Aucun membre ( staticou non) Formatn'existe dessus (ou n'est hérité de sa classe de base). Et la valeur"Goodbye" ne peut pas y être convertie.

L'utilisation de types de système facilite le portage entre C # et VB.Net, si vous êtes dans ce genre de chose.

Contre ce qui semble être une pratique courante parmi d'autres programmeurs, je préfère Stringplus string, juste pour souligner le fait qu'il Strings'agit d'un type de référence, comme l'a mentionné Jon Skeet.

stringest un alias (ou raccourci) de System.String. Cela signifie qu'en tapant, stringnous voulions dire System.String. Vous pouvez en savoir plus dans think link: 'string' est un alias / raccourci de System.String.

Je voudrais juste ajouter ceci à la réponse lfousts, du livre Ritchers:

La spécification du langage C # stipule: "Pour une question de style, l'utilisation du mot-clé est préférée à l'utilisation du nom complet du type de système." Je suis en désaccord avec la spécification de la langue; Je préfère utiliser les noms de type FCL et éviter complètement les noms de type primitifs. En fait, je souhaite que les compilateurs n'offrent même pas les noms de type primitifs et obligent les développeurs à utiliser à la place les noms de type FCL. Voici mes raisons:

• J'ai vu un certain nombre de développeurs confus, ne sachant pas s'il fallait utiliser une chaîne ou une chaîne dans leur code. Parce que dans la chaîne C # (un mot-clé) correspond exactement à System.String (un type FCL), il n'y a aucune différence et l'un ou l'autre peut être utilisé. De même, j'ai entendu certains développeurs dire que int représente un entier 32 bits lorsque l'application s'exécute sur un système d'exploitation 32 bits et qu'il représente un entier 64 bits lorsque l'application s'exécute sur un système d'exploitation 64 bits. Cette affirmation est absolument fausse: en C #, un int correspond toujours à System.Int32 et représente donc un entier 32 bits quel que soit le système d'exploitation sur lequel le code s'exécute. Si les programmeurs utilisaientInt32 dans leur code, cette confusion potentielle est également éliminée.

• En C #, les mappages longs vers System.Int64 , mais dans un langage de programmation différent, long peuvent mapper vers un Int16 ou Int32 . En fait, C ++ / CLI traite longtemps comme un Int32 . Quelqu'un qui lit le code source dans une langue pourrait facilement mal interpréter l'intention du code s'il était habitué à programmer dans un autre langage de programmation. 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 possède de nombreuses méthodes dont les noms de type font partie de leurs noms de méthode. Par exemple, le type BinaryReader propose des méthodes telles que ReadBoolean , ReadInt32 , ReadSingle , etc. 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 peu naturelle, 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

• De nombreux programmeurs qui utilisent exclusivement C # ont tendance à oublier que d'autres langages de programmation peuvent être utilisés contre le CLR, et à cause de cela, les mécanismes C # se glissent dans le code de bibliothèque de classes. Par exemple, le FCL de Microsoft est presque exclusivement écrit en C # et les développeurs de l'équipe FCL ont maintenant introduit des méthodes dans la bibliothèque telles que Array « de GetLongLength , qui renvoie une Int64 valeur qui est une longue en C # , mais pas dans d' autres langues (comme C ++ / CLI). Un autre exemple est System.Linq.Enumerable de LongCount méthode.

Je n'ai pas eu son opinion avant de lire le paragraphe complet.

Chaîne (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.

Stringn'est pas un mot-clé et il peut être utilisé comme identifiant alors qu'il stringest un mot-clé et ne peut pas être utilisé comme identifiant. Et du point de vue fonctionnel, les deux sont identiques.

C'est une question de convention, vraiment. stringressemble plus au style C / C ++. La convention générale consiste à utiliser les raccourcis fournis par votre langue choisie (int / Int pour Int32). Cela vaut pour "objet" etdecimal aussi.

Théoriquement, cela pourrait aider à porter du code dans une future norme 64 bits dans laquelle "int" pourrait signifier Int64, mais ce n'est pas le point, et je m'attendrais à ce que tout assistant de mise à niveau modifie toutes les intréférences de Int32toute façon juste pour être sûr.

Venir en retard à la fête: j'utilise les types CLR 100% du temps (enfin, sauf si forcé d'utiliser le type C #, mais je ne me souviens pas 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 était logique pour moi que tous les langages CLR doivent finalement être en mesure de prendre en charge l'ensemble des types CLR, donc l'utilisation des types CLR vous-même a fourni un code plus clair et peut-être plus "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 véritable inconvénient est que la saisie semi-automatique utilise le type C #, donc je finis par retaper les types générés automatiquement pour spécifier le type CLR à la place.

De plus, maintenant, quand je vois "int" ou "string", cela me semble vraiment mal, comme si je regardais le code C des années 70.

Il n'y a pas de différence.

Le mot clé C # stringcorrespond au type .NET System.String- c'est un alias qui respecte les conventions de dénomination du langage.

De même, les intcartesSystem.Int32 .

Il y a une citation sur cette question de le livre Daniel Solis .

Tous les types prédéfinis sont mappés directement aux types .NET sous-jacents. Les noms de type C # (chaîne) sont simplement des alias pour les types .NET (String ou System.String), donc l'utilisation des noms .NET fonctionne bien syntaxiquement, bien que cela soit déconseillé. Dans un programme C #, vous devez utiliser les noms C # plutôt que les noms .NET.

chaîne est un mot clé et vous ne pouvez pas utiliser de chaîne comme identifiant.

La chaîne n'est pas un mot clé et vous pouvez l'utiliser comme identifiant:

Exemple

string String = "I am a string";

Le mot string - clé est un alias car en System.Stringdehors du problème de mot-clé, les deux sont exactement équivalents.

 typeof(string) == typeof(String) == typeof(System.String)

Oui, ce n'est pas une différence entre eux, tout comme les boolet Boolean.

@JaredPar (développeur du compilateur C # et utilisateur prolifique de SO!) A écrit un excellent article de blog sur ce problème. Je pense que cela vaut la peine d'être partagé ici. C'est une belle perspective sur notre sujet.

stringvs Stringn'est pas un débat de style

[...]

Le mot-clé stringa une signification concrète en C #. Il s'agit du type System.Stringqui existe dans l'assembly d'exécution principal. Le runtime comprend intrinsèquement ce type et fournit les capacités que les développeurs attendent pour les chaînes dans .NET. Sa présence est si critique pour C # que si ce type n'existe pas, le compilateur se fermera avant d'essayer même d'analyser une ligne de code. A donc stringune signification précise et non ambiguë dans le code C #.

L'identifiant Stringn'a cependant aucune signification concrète en C #. Il est un identifiant qui passe par toutes les règles recherche le nom comme Widget, Student, etc ... Il peut se lier à la chaîne ou il pourrait se lier à un type dans une autre assemblée entièrement dont les buts peuvent être tout à fait différent de celui string. Pire, il pourrait être défini d'une manière telle qu'un code comme String s = "hello"; a continué de compiler.

class TricksterString { 
  void Example() {
    String s = "Hello World"; // Okay but probably not what you expect.
  }
}

class String {
  public static implicit operator String(string s) => null;
}

La signification réelle de Stringdépendra toujours de la résolution du nom. Cela signifie que cela dépend de tous les fichiers source du projet et de tous les types définis dans tous les assemblys référencés. Bref il faut pas mal de contexte pour savoir ce que cela signifie.

Il est vrai que dans la grande majorité des cas Stringet stringse liera au même type. Mais l'utilisation Stringsignifie toujours que les développeurs laissent leur programme à l'interprétation dans des endroits où il n'y a qu'une seule bonne réponse. Quand Stringse lie au mauvais type, cela peut laisser les développeurs déboguer pendant des heures, déposer des bogues sur l'équipe du compilateur et perdre généralement du temps qui aurait pu être économisé en utilisant string.

Une autre façon de visualiser la différence est avec cet exemple:

string s1 = 42; // Errors 100% of the time  
String s2 = 42; // Might error, might not, depends on the code

Beaucoup diront que même si ces informations sont techniquement exactes, leur utilisation Stringest toujours très bien car il est extrêmement rare qu'une base de code définisse un type de ce nom. Ou que lorsqu'il Stringest défini, c'est le signe d'une mauvaise base de code.

[...]

Vous verrez que cela Stringest défini pour un certain nombre d'objectifs tout à fait valides: assistants de réflexion, bibliothèques de sérialisation, lexers, protocoles, etc. Pour n'importe laquelle de ces bibliothèques Stringvsstring a des conséquences réelles selon l'endroit où le code est utilisé.

Alors souvenez-vous que lorsque vous voyez le débat Stringcontre string, il s'agit de sémantique, pas de style. Le choix de la chaîne donne une signification claire à votre base de code. Choisir Stringn'est pas mal, mais cela laisse la porte ouverte à des surprises à l'avenir.

Remarque: J'ai copié / collé la plupart des articles de blog pour des raisons d'archivage. J'ignore certaines parties, je vous recommande donc de sauter et de lire le blog si vous le pouvez.