Question

Exemple (noter le cas):

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

Que sont les des lignes directrices pour l'usage de chacun ?Et quels sont les différences?

Était-ce utile?

La solution

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

En ce qui concerne les lignes directrices, il est généralement recommandé d'utiliser string à chaque 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 String si vous avez besoin de 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 leurs exemples.

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

Autres conseils

Juste par souci d'exhaustivité, voici un brain dump d'informations connexes...

Comme d'autres l'ont noté, string est un pseudonyme pour System.String.Ils compilent avec 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

En dehors de string et object, les alias sont tous des types valeur. decimal est un type 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 permet DateTime littéraux, et a également un alias pour cela.)

Il y a une circonstance dans laquelle vous avoir pour 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 type intégral production, qui est un gage de sbyte, byte, short, ushort, int, uint, long, ulong, char...contrairement à un taper production tel qu'utilisé par les déclarations de variables par exemple.Cela n'indique aucune autre différence.

Enfin, quand il s’agit de savoir quoi 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 au sein de votre équipe est une bonne chose, mais personne d'autre ne s'en souciera.D'un autre côté, il est vraiment important que si vous faites référence à un type dans une API, vous le fassiez d'une manière neutre en termes de langage.Une méthode appelée ReadInt32 est sans ambiguïté, alors qu'une méthode appelée ReadInt nécessite une interprétation.L'appelant peut utiliser un langage qui définit un int pseudonyme pour Int16, Par exemple.Les concepteurs du framework .NET ont suivi ce modèle, de bons exemples étant dans BitConverter, BinaryReader et Convert Des classes.

String représente System.String et c'est un type .NET Framework. string est un pseudonyme en langage C# pour System.String.Les deux sont compilés pour System.String en Illinois (Langue intermédiaire), il n'y a donc aucune différence.Choisissez ce que vous aimez et utilisez-le.Si vous codez en C#, je préférerais string car il s'agit d'un alias de type C# et bien connu des programmeurs C#.

Je peux dire la même chose de (int, System.Int32) etc..

La meilleure réponse que j'ai jamais entendue 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 s'il fallait utiliser chaîne ou 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 aucune différence et l'un ou l'autre peut être utilisé.
  • En C#, long cartes à Système.Int64, mais dans un langage de programmation différent, long pourrait correspondre à un Int16 ou Int32.En fait, C++/CLI traite en fait long comme un Int32.Quelqu'un lisant le code source dans une langue pourrait facilement mal interpréter l'intention du code s'il était habitué à programmer dans un langage de programmation différent.En fait, la plupart des langues ne traitent même pas long comme mot-clé et ne compilera pas le code qui l'utilise.
  • La FCL comporte de nombreuses méthodes dont les noms de type font partie de leurs noms de méthode.Par exemple, le LecteurBinaire type propose des méthodes telles que LireBooléen, LectureInt32, LireSingle, et ainsi de suite, et le Système.Convertir type propose des méthodes telles que VersBooléen, VersInt32, Selectionner, et ainsi de suite.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 est juste un nom de classe.Cela signifie que string ne 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 utiliser @ comme préfixe :

StringBuilder @string = new StringBuilder();

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

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

Cela a été couvert ci-dessus ;cependant, vous ne pouvez pas utiliser string en réflexion;Tu dois utiliser String.

System.String est la classe de chaîne .NET - en C# string est un pseudonyme pour System.String - donc à l'usage, ce sont les mêmes.

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

Si vous construisez des systèmes dans lesquels il est nécessaire de spécifier la taille des entiers que vous utilisez et avez donc tendance à utiliser Int16, Int32, UInt16, UInt32 etc.alors il pourrait sembler plus naturel d'utiliser String - et lorsque je me déplace entre différentes langues .net, cela pourrait rendre les choses plus compréhensibles - sinon j'utiliserais string et int.

je préfère les majuscules .NET types (plutôt que les alias) pour des raisons de formatage.Le .NET les types sont colorés de la même manière que les autres types d’objets (les types valeur sont des objets appropriés, après tout).

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

Considérer:

String someString; 
string anotherString; 

string et String sont identiques en tous points (sauf le « S » majuscule).Il n’y a aucune implication en termes de performances dans tous les cas.

Minuscule string est préféré 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 dans le CLR.

Lorsque vous utilisez C# avec le CLR string sera mappé à System.String.

Théoriquement, vous pourriez implémenter un compilateur C# générant du bytecode Java.Une implémentation judicieuse de ce compilateur mapperait probablement string à java.lang.String afin d'interagir avec la bibliothèque d'exécution Java.

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

Mais maintenant, une longue réponse textuelle.

Quand on parle de .NET il y a deux choses différentes, une seule existe .NET framework et l’autre il y a des langages ( C# , VB.NET etc) qui utilisent ce framework.

enter image description here

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

enter image description here

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 le même résultat.

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, octet : 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 toute confusion est d’en utiliser un de manière cohérente.Mais du point de vue des meilleures pratiques, lorsque vous effectuez une déclaration de variable, il est bon d'utiliser "string" (petit "s") et lorsque vous l'utilisez comme nom de classe, alors "String" ("S" majuscule) est préféré.

Dans le code ci-dessous, le côté gauche est une déclaration de variable et elle est déclarée à l'aide de "string".Sur le côté droit, nous appelons une méthode donc "String" est plus logique.

string s = String.ToUpper() ;

Minuscules string est un pseudonyme pour System.String.Ce sont les mêmes dans C#.

Il y a un débat sur la question de savoir si vous devez utiliser les types système (System.Int32, System.String, etc.) ou les C# aliases (int, string, etc).Personnellement, je pense que vous devriez utiliser le C# aliases, mais ce n'est que ma préférence personnelle.

string est juste un pseudonyme pour System.String.Le compilateur les traitera de la même manière.

La seule différence pratique est la coloration syntaxique comme vous le mentionnez, et le fait que vous devez écrire using System si tu utilises String.

Les deux sont identiques.Mais du point de vue des directives de codage, il est préférable d'utiliser string au lieu de String.C’est ce qu’utilisent généralement les développeurs.par exemple.à la place d'utiliser Int32 nous utilisons int comme int est un pseudonyme pour Int32

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

Comme le disent les autres, ce sont les mêmes.Les règles StyleCop, par défaut, vous obligeront à utiliser string comme meilleure pratique de style de code C#, sauf lors du référencement System.String fonctions statiques, telles que String.Format, String.Join, String.Concat, etc...

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

Alors que string est un mot clé C# réservé qui a toujours une signification fixe, String c'est juste un ordinaire identifiant qui pourrait faire référence à n'importe quoi.En fonction des membres du type actuel, de l'espace de noms actuel et de l'application using les directives et leur placement, String pourrait être une valeur ou un type distinct de global::System.String.

Je vais donner deux exemples où using les directives n'aideront pas.


D'abord, quand String est un valeur du type courant (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<> n'a pas de membre non statique appelé Format, et aucune méthode d'extension ne s'applique.Dans le cas ci-dessus, il peut toujours être possible d'utiliser String dans d'autres contextes où un taper est la seule possibilité syntaxiquement.Par exemple String local = "Hi mum!"; pourrait être OK (en fonction de l'espace de noms et using directives).

Pire:En disant String.Concat(someSequence) sera probablement (en fonction de usings) allez à la méthode d'extension Linq Enumerable.Concat.Cela n'ira pas à la méthode statique string.Concat.


Deuxièmement, quand String est un autre taper, 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 des déclarations dans le Example la méthode compile.Ici String c'est toujours un piano chaîne, MyPiano.String.Aucun membre (static ou non) Format existe dessus (ou est hérité de sa classe de base).Et la valeur "Goodbye" ne peut pas être converti en celui-ci.

L'utilisation des types système facilite le portage entre C# et VB.Net, si vous aimez ce genre de choses.

Contrairement à ce qui semble être une pratique courante chez 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é.

string est un alias (ou un raccourci) de System.String.Cela signifie qu'en tapant string nous voulions dire System.String.Vous pouvez en savoir plus sur le lien Think : 'string' est un alias/abréviation de System.String.

Chaîne (System.String) est une classe de la bibliothèque de classes de base.string (minuscules) 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 au C.

Je voudrais juste ajouter ceci à la réponse de Lfousts, tirée du livre de Ritchers :

La spécification du langage C # indique: «En style, l'utilisation du mot-clé est privilégiée par rapport à l'utilisation du nom complet du type de système.» Je ne suis pas d'accord avec la spécification linguistique;Je préfère utiliser les noms de type FCL et éviter complètement les noms de type primitif.En fait, je souhaite que les compilateurs n'offrent même pas les noms de type primitifs et les développeurs forcés à utiliser les noms de type FCL à la place.Voici mes raisons :

  • J'ai vu un certain nombre de développeurs confus, ne sachant pas s'ils devaient utiliser chaîneou Chaîne dans leur code.Parce qu'en C# chaîne (un mot-clé) correspond exactement à Système.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 fonctionne sur un système d'exploitation 32 bits et qu'il représente un entier 64 bits lorsque l'application fonctionne sur un système d'exploitation 64 bits.Cette affirmation est absolument fausse :en C#, un int Mapes toujours à Système.Int32, et donc il représente un entier 32 bits quel que soit le code sur lequel le code fonctionne.Si les programmeurs utilisaient Int32 Dans leur code, cette confusion potentielle est également éliminée.

  • En C#, long cartes à Système.Int64, mais dans un langage de programmation différent, longpourrait correspondre à un Int16 ou Int32.En fait, C++/CLI traite long comme un Int32.Quelqu'un lisant le code source dans une langue pourrait facilement mal interpréter l'intention du code s'il avait l'habitude de programmer dans un langage de programmation différent.En fait, la plupart des langues ne traitent même pas long comme mot-clé et ne compile pas le code qui l'utilise.

  • La FCL comporte de nombreuses méthodes dont les noms de type font partie de leurs noms de méthode.Par exemple, le LecteurBinaire type propose des méthodes telles que LireBooléen, LectureInt32, LireSingle, et ainsi de suite, et le Système.Convertir type propose des méthodes telles que VersBooléen, VersInt32, Selectionner, et ainsi de suite.Bien qu'il soit légal d'écrire le code suivant, la ligne avec flotter me semble très naturel, et il n'est pas évident que la ligne est 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 C # ont tendance à oublier que d'autres langages de programmation peuvent être utilisés contre le CLR, et à cause de cela, C # -isms se glisse dans le code de la bibliothèque de classe.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 Tableauc'est ObtenirLongLongueur, qui renvoie un Int64 valeur qui est une long en C # mais pas dans d'autres langues (comme C ++ / CLI).Un autre exemple est System.Linq.Enumerablec'est Compte Long méthode.

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

String n'est pas un mot-clé et peut être utilisé comme identifiant alors que string est un mot-clé et ne peut pas être utilisé comme identifiant.Et du point de vue fonctionnel, les deux sont identiques.

Arriver en retard à la fête :J'utilise les types CLR 100% du temps (enfin, sauf si forcé pour utiliser le type C#, mais je ne me souviens pas de la dernière fois).

J'ai commencé à faire cela il y a des années, conformément aux livres CLR de Ritchie.Il me paraissait logique que tous les langages CLR doivent en fin de compte être capables de prendre en charge l'ensemble des types CLR, donc l'utilisation des types CLR vous-même fournissait 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 montre VS 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 faux, comme si je regardais le code C des années 1970.

C'est vraiment une question de convention. string ressemble plus au style C/C++.La convention générale est d'utiliser les raccourcis fournis par la langue de votre choix (int/Int pour Int32).Cela vaut pour "objet" et decimal aussi.

Théoriquement, cela pourrait aider à porter le code dans une future norme 64 bits dans laquelle « int » pourrait signifier Int64, mais ce n'est pas le sujet, et je m'attendrais à ce que n'importe quel assistant de mise à niveau modifie tout int les références à Int32 en tout cas, juste pour être en sécurité.

Il n'y a pas de différence.

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

De la même manière, int cartes à System.Int32.

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

Tous les types prédéfinis sont mappés directement aux types de .NET sous-jacents.Les noms de types C # (String) 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écouragé.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.

Chaîne n'est pas un mot-clé, et vous pouvez l'utiliser comme identifiant :

Exemple

string String = "I am a string";

Le mot clé string est un pseudonyme pour System.String Mis à part le problème des mots clés, les deux sont exactement équivalents.

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

Oui, il n'y a pas de différence entre eux, tout comme le bool et Boolean.

Il n'y a pas de différence entre les deux - string, cependant, semble être l'option préférée lorsque l'on considère le code source d'autres développeurs.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top