Esempio ( notare il caso ):

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

Quali sono le linee guida per l'uso di ciascuno? E quali sono le differenze?

stringè un alias in C # per System.String.
Quindi tecnicamente, non c'è differenza. E 'come int contro System.Int32 .

Per quanto riguarda le linee guida, in genere si consiglia di utilizzare stringogni volta che ci si riferisce a un oggetto.

per esempio

string place = "world";

Allo stesso modo, penso che sia generalmente raccomandato l'uso Stringse è necessario fare riferimento in modo specifico alla classe.

per esempio

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

Questo è lo stile che Microsoft tende ad usare nei loro esempi .

Sembra che la guida in quest'area possa essere cambiata, poiché StyleCop ora impone l'uso degli alias specifici di C #.

Solo per completezza, ecco una discarica di informazioni correlate ...

Come altri hanno notato, stringè un alias per System.String. Si compilano con lo stesso codice, quindi al momento dell'esecuzione non c'è alcuna differenza. Questo è solo uno degli alias in C #. L'elenco completo è:

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

A parte stringe object, gli alias sono tutti di tipi di valore. decimalè un tipo di valore, ma non un tipo primitivo nel CLR. L'unico tipo primitivo che non ha un alias è System.IntPtr.

Nella specifica, gli alias del tipo di valore sono noti come "tipi semplici". I letterali possono essere usati per valori costanti di ogni tipo semplice; nessun altro tipo di valore ha forme letterali disponibili. (Confronta questo con VB, che consente i DateTimeletterali e ha anche un alias per esso.)

V'è una circostanza in cui si deve usare gli alias: quando si specifica in modo esplicito tipo sottostante di un enum. Per esempio:

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

Questo è solo un aspetto del modo in cui definisce enum dichiarazioni spec - la parte dopo il colon deve essere l' integrale di tipo di produzione, che è un gettone di sbyte, byte, short, ushort, int, uint, long, ulong, char... al contrario di un tipo di produzione utilizzato ad esempio da dichiarazioni di variabili. Non indica alcuna altra differenza.

Infine, quando si tratta di quale utilizzare: personalmente uso gli alias ovunque per l'implementazione, ma il tipo CLR per qualsiasi API. In realtà non importa molto quale usi in termini di implementazione: la coerenza tra il tuo team è buona, ma a nessuno importa. D'altra parte, è veramente importante che se si fa riferimento a un tipo in un'API, lo si fa in modo neutrale rispetto al linguaggio. Un metodo chiamato ReadInt32non è ambiguo, mentre un metodo chiamato ReadIntrichiede interpretazione. Ad esempio, il chiamante potrebbe utilizzare una lingua che definisce un intalias Int16. I progettisti di .NET framework hanno seguito questo schema, un buon esempio essendo nelle BitConverter, BinaryReadere Convertclassi.

Stringsta per System.Stringed è un tipo .NET Framework. stringè un alias nel linguaggio C # per System.String. Entrambi sono compilati System.Stringin IL (Intermediate Language), quindi non c'è differenza. Scegli quello che ti piace e usalo. Se codifichi in C #, preferirei stringche sia un alias di tipo C # e ben noto ai programmatori C #.

Posso dire lo stesso di ( int, System.Int32) ecc.

La migliore risposta che io abbia mai sentito sull'uso dell'alias di tipo fornito in C # viene da Jeffrey Richter nel suo libro CLR Via C # . Ecco i suoi 3 motivi:

• Ho visto diversi sviluppatori confusi, non sapendo se usare la stringa o la stringa nel loro codice. Perché in C # la stringa (una parola chiave) si associa esattamente a System.String (un tipo FCL), non vi è alcuna differenza ed è possibile utilizzare entrambi.
• In C #, long esegue il mapping a System.Int64 , ma in un linguaggio di programmazione diverso, long può eseguire il mapping a Int16 o Int32 . In effetti, C ++ / CLI in effetti tratta come Int32 . Qualcuno che legge il codice sorgente in una lingua potrebbe facilmente interpretare male l'intenzione del codice se fosse abituato a programmare in un linguaggio di programmazione diverso. In effetti, la maggior parte delle lingue non tratterà nemmeno a lungo come una parola chiave e non compilerà il codice che la utilizza.
• La FCL ha molti metodi che hanno nomi di tipi come parte dei loro nomi di metodi. Ad esempio, il tipo BinaryReader offre metodi come ReadBoolean , ReadInt32 , ReadSingle e così via, mentre il tipo System.Convert offre metodi come ToBoolean , ToInt32 , ToSingle e così via. Sebbene sia legale scrivere il seguente codice, la riga con float mi sembra molto innaturale e non è ovvio che la riga sia corretta:

BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

Così il gioco è fatto. Penso che questi siano tutti punti davvero positivi. Tuttavia, non mi ritrovo ad usare i consigli di Jeffrey nel mio codice. Forse sono troppo bloccato nel mio mondo C # ma finisco per provare a rendere il mio codice simile al codice del framework.

stringè una parola riservata, ma Stringè solo un nome di classe. Ciò significa che stringnon può essere utilizzato come nome di variabile da solo.

Se per qualche motivo volessi una variabile chiamata stringa , vedresti solo la prima di queste compilazioni:

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

Se vuoi davvero un nome di variabile chiamato stringa puoi usare @come prefisso:

StringBuilder @string = new StringBuilder();

Un'altra differenza fondamentale: Stack Overflow li evidenzia in modo diverso.

C'è una differenza : non puoi usarlo Stringsenza using System;prima.

È stato coperto sopra; tuttavia, non è possibile utilizzare stringnella riflessione; devi usare String.

System.Stringè la classe di stringhe .NET - in C # stringè un alias per System.String- quindi in uso sono uguali.

Per quanto riguarda le linee guida, non mi impantanerei troppo e utilizzerei semplicemente quello che pensi: ci sono cose più importanti nella vita e il codice sarà lo stesso comunque.

Se vi trovate sistemi in cui è necessario costruire per specificare la dimensione degli interi che si sta utilizzando e quindi tendono ad usare Int16, Int32, UInt16, UInt32ecc allora potrebbe sembrare più naturale da usare String- e durante gli spostamenti tra i diversi linguaggi .net potrebbe rendere le cose più comprensibili, altrimenti userei string e int.

Preferisco i .NETtipi maiuscoli (piuttosto che gli alias) per motivi di formattazione. I .NETtipi sono colorati come gli altri tipi di oggetti (i tipi di valore sono oggetti propri, dopo tutto).

Le parole chiave condizionali e di controllo (come if, switche return) sono minuscole e colorate di blu scuro (per impostazione predefinita). E preferirei non avere il disaccordo nell'uso e nel formato.

Prendere in considerazione:

String someString; 
string anotherString; 

stringe Stringsono identici in tutti i modi (tranne la "S" maiuscola). Non ci sono implicazioni sulle prestazioni in entrambi i casi.

Il carattere minuscolo stringè preferito nella maggior parte dei progetti a causa dell'evidenziazione della sintassi

C # è un linguaggio che viene utilizzato insieme al CLR.

string è un tipo in C #.

System.String è un tipo nel CLR.

Quando si utilizza C # insieme al CLR stringverrà mappato System.String.

Teoricamente, potresti implementare un compilatore C # che ha generato il bytecode Java. Un'implementazione sensibile di questo compilatore probabilmente mappa stringper java.lang.Stringal fine di interagire con la libreria di runtime Java.

Questo video di YouTube dimostra praticamente come differiscono.

Ma ora per una lunga risposta testuale.

Quando si parla di .NETci sono due cose diverse c'è un .NETquadro e l'altro ci sono lingue ( C#, VB.NETecc) che utilizzano tale contesto.

" System.String" aka "String" (maiuscola "S") è un .NETtipo di dati del framework mentre "string" è un C#tipo di dati.

In breve "String" è un alias (la stessa cosa chiamata con nomi diversi) di "string". Quindi tecnicamente entrambe le istruzioni di codice riportate di seguito daranno lo stesso output.

String s = "I am String";

o

string s = "I am String";

Allo stesso modo ci sono alias per altri tipi di dati c # come mostrato di seguito: -

oggetto: System.Object, stringa: System.String, bool: System.Boolean, byte: System.Byte, sbyte: System.SBytecorto: System.Int16e così via

Ora la domanda da un milione di dollari dal punto di vista del programmatore Quindi quando usare "String" e "string"?

Per prima cosa, per evitare confusione, usarne una in modo coerente. Ma dal punto di vista delle migliori pratiche quando si fa una dichiarazione variabile è bene usare "string" (piccole "s") e quando lo si utilizza come nome di classe, si preferisce "String" (maiuscola "S").

Nel codice sottostante il lato sinistro è una dichiarazione variabile e dichiarata usando "stringa". Sul lato destro stiamo chiamando un metodo, quindi "String" è più sensato.

string s = String.ToUpper() ;

Le lettere minuscole stringsono un alias per System.String. Sono gli stessi dentro C#.

C'è un dibattito sul fatto che si dovrebbe utilizzare i tipi di sistema ( System.Int32, System.String, ecc) tipi o la C# aliases( int, string, ecc). Personalmente credo che dovresti usare il C# aliases, ma questa è solo la mia preferenza personale.

stringè solo un alias per System.String. Il compilatore li tratterà in modo identico.

L'unica differenza pratica è l'evidenziazione della sintassi mentre menzioni e che devi scrivere using Systemse lo usi String.

Entrambi sono uguali. Ma dal punto di vista delle linee guida di codifica è meglio usare stringinvece di String. Questo è ciò che generalmente usano gli sviluppatori. ad es. invece di usare Int32usiamo intcome intè alias aInt32

Cordiali saluti "La stringa di parole chiave è semplicemente un alias per la classe predefinita System.String." - Specifica del linguaggio C # 4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

Come dicono gli altri, sono gli stessi. Regole StyleCop, per impostazione predefinita, faranno rispettare l'utilizzo di stringun codice di stile C # migliori pratiche, ad eccezione di quando si fa riferimento System.Stringfunzioni statiche, ad esempio String.Format, String.Join, String.Concat, ecc ...

Nuova risposta dopo 6 anni e 5 mesi (procrastinazione).

Mentre stringè una parola chiave riservata C # che ha sempre un significato fisso, Stringè solo un identificatore ordinario che potrebbe riferirsi a qualsiasi cosa. A seconda dei membri del tipo corrente, lo spazio dei nomi corrente e le usingdirettive applicate e il loro posizionamento Stringpotrebbero essere un valore o un tipo distinti da global::System.String.

Fornirò due esempi in cui le usingdirettive non aiuteranno .

Innanzitutto, quando Stringè un valore del tipo corrente (o una variabile locale):

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

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

Quanto sopra non verrà compilato perché IEnumerable<>non ha un membro non statico chiamato Formate non si applicano metodi di estensione. Nel caso precedente, potrebbe essere ancora possibile utilizzare Stringin altri contesti in cui un tipo è l'unica possibilità sintatticamente. Ad esempio, String local = "Hi mum!";potrebbe essere OK (a seconda dello spazio dei nomi e delle usingdirettive).

Peggio ancora: dire String.Concat(someSequence)che probabilmente (a seconda dei using) andrà al metodo di estensione Linq Enumerable.Concat. Non andrà al metodo statico string.Concat.

In secondo luogo, quando Stringè un altro tipo , nidificato all'interno del tipo corrente:

class MyPiano
{
  protected class String
  {
  }

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

Nessuna delle istruzioni nel Examplemetodo viene compilata. Qui Stringè sempre un pianoforte archi , MyPiano.String. Nessun membro ( statico no) Formatesiste (o è ereditato dalla sua classe base). E il valore "Goodbye"non può essere convertito in esso.

L'uso dei tipi di sistema semplifica il trasferimento tra C # e VB.Net, se ti interessa questo tipo di cose.

Contro quello che sembra essere una pratica comune tra gli altri programmatori, preferisco Stringsopra string, solo per evidenziare il fatto che Stringè un tipo di riferimento, come detto Jon Skeet.

stringè un alias (o stenografia) di System.String. Ciò significa che digitando stringintendevamo System.String. Puoi leggere di più in think link: 'string' è un alias / abbreviazione di System.String.

Vorrei solo aggiungere questo alla risposta di lfousts, dal libro di Ritchers:

La specifica del linguaggio C # afferma: "Per motivi di stile, l'uso della parola chiave è preferito rispetto all'uso del nome completo del tipo di sistema". Non sono d'accordo con le specifiche del linguaggio; Preferisco usare i nomi dei tipi FCL ed evitare completamente i nomi dei tipi primitivi. In realtà, vorrei che i compilatori non offrissero nemmeno i nomi dei tipi primitivi e costringessero gli sviluppatori a usare i nomi dei tipi FCL. Ecco i miei motivi:

• Ho visto diversi sviluppatori confusi, non sapendo se usare la stringa o la stringa nel loro codice. Perché nella stringa C # (una parola chiave) si associa esattamente a System.String (un tipo FCL), non vi è alcuna differenza ed è possibile utilizzare entrambi. Allo stesso modo, ho sentito alcuni sviluppatori dire che int rappresenta un numero intero a 32 bit quando l'applicazione è in esecuzione su un sistema operativo a 32 bit e che rappresenta un numero intero a 64 bit quando l'applicazione è in esecuzione su un sistema operativo a 64 bit. Questa affermazione è assolutamente falsa: in C #, un int è sempre mappato a System.Int32 e quindi rappresenta un numero intero a 32 bit indipendentemente dal sistema operativo su cui è in esecuzione il codice. Se i programmatori avrebbero usatoInt32 nel loro codice, quindi anche questa potenziale confusione viene eliminata.

• In C #, long esegue il mapping a System.Int64 , ma in un linguaggio di programmazione diverso, long può eseguire il mapping a Int16 o Int32 . Infatti, C ++ / CLI fa piacere lungo come Int32 . Qualcuno che legge il codice sorgente in una lingua potrebbe facilmente interpretare male l'intenzione del codice se fosse abituato a programmare in un linguaggio di programmazione diverso. In effetti, la maggior parte delle lingue non tratterà nemmeno a lungo come una parola chiave e non compilerà il codice che la utilizza.

• La FCL ha molti metodi che hanno nomi di tipi come parte dei loro nomi di metodi. Ad esempio, il tipo BinaryReader offre metodi come ReadBoolean , ReadInt32 , ReadSingle e così via, mentre il tipo System.Convert offre metodi come ToBoolean , ToInt32 , ToSingle e così via. Sebbene sia legale scrivere il seguente codice, la riga con float mi sembra molto innaturale e non è ovvio che la riga sia corretta:

  BinaryReader br = new BinaryReader(...);
  float val = br.ReadSingle(); // OK, but feels unnatural
  Single val = br.ReadSingle(); // OK and feels good

• Molti programmatori che usano C # tendono esclusivamente a dimenticare che altri linguaggi di programmazione possono essere usati contro il CLR, e per questo motivo i meccanismi C # si insinuano nel codice della libreria di classi. Ad esempio, FCL di Microsoft è quasi scritto esclusivamente in C # e sviluppatori del team di FCL hanno introdotto metodi nella libreria, come Array ‘s GetLongLength , che restituisce un Int64 valore che è un lungo in C #, ma non in altre lingue (come il C ++ / CLI). Un altro esempio è System.Linq.Enumerable s’ LongCount metodo.

Non ho ottenuto la sua opinione prima di leggere il paragrafo completo.

String ( System.String) è una classe nella libreria di classi base. string (in minuscolo) è un lavoro riservato in C # che è un alias per System.String. Int32 vs int è una situazione simile com'è Boolean vs. bool. Queste parole chiave specifiche del linguaggio C # ti consentono di dichiarare le primitive in uno stile simile a C.

Stringnon è una parola chiave e può essere utilizzata come identificatore, mentre stringè una parola chiave e non può essere utilizzata come identificatore. E dal punto di vista funzionale entrambi sono uguali.

È una questione di convenzioni, davvero. stringassomiglia di più allo stile C / C ++. La convenzione generale consiste nell'utilizzare qualsiasi scorciatoia fornita dalla lingua scelta (int / Int Int32). Questo vale per "oggetto" e decimalpure.

Teoricamente questo potrebbe aiutare a convertire il codice in un futuro standard a 64 bit in cui "int" potrebbe significare Int64, ma non è questo il punto, e mi aspetterei che qualsiasi procedura guidata di aggiornamento cambi comunque qualsiasi intriferimento Int32solo per sicurezza.

Venire tardi alla festa: uso i tipi CLR il 100% delle volte (beh, tranne se costretto a usare il tipo C #, ma non ricordo quando è stata l'ultima volta).

Inizialmente ho iniziato a farlo anni fa, secondo i libri CLR di Ritchie. Per me aveva senso che tutti i linguaggi CLR alla fine dovessero essere in grado di supportare l'insieme dei tipi CLR, quindi l'uso dei tipi CLR da soli fornito codice più chiaro e forse più "riutilizzabile".

Ora che lo faccio da anni, è un'abitudine e mi piace la colorazione che VS mostra per i tipi CLR.

L'unico aspetto negativo è che il completamento automatico utilizza il tipo C #, quindi finisco per riscrivere i tipi generati automaticamente per specificare il tipo CLR.

Inoltre, ora, quando vedo "int" o "string", mi sembra davvero sbagliato, come se stessi guardando il codice C degli anni '70.

Non c'è differenza.

La parola chiave C # si stringassocia al tipo .NET System.String: è un alias che mantiene le convenzioni di denominazione del linguaggio.

Allo stesso modo, intmappa a System.Int32.

C'è una citazione su questo numero dal libro di Daniel Solis .

Tutti i tipi predefiniti sono associati direttamente ai tipi .NET sottostanti. I nomi dei tipi C # (stringa) sono semplicemente alias per i tipi .NET (String o System.String), quindi l'utilizzo dei nomi .NET funziona in modo sintattico, sebbene questo sia scoraggiato. All'interno di un programma C #, è necessario utilizzare i nomi C # anziché i nomi .NET.

stringa è una parola chiave e non è possibile utilizzare la stringa come identificatore.

String non è una parola chiave e puoi usarla come identificatore:

Esempio

string String = "I am a string";

La parola chiave string è un alias a System.Stringparte il problema della parola chiave, i due sono esattamente equivalenti.

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

Sì, non c'è alcuna differenza tra loro, proprio come il boole Boolean.

@JaredPar (uno sviluppatore del compilatore C # e un prolifico utente SO!) Ha scritto un ottimo post sul blog su questo problema. Penso che valga la pena condividere qui. È una bella prospettiva sul nostro argomento.

stringvs. Stringnon è un dibattito di stile

[...]

La parola chiave stringha un significato concreto in C #. È il tipo System.Stringesistente nell'assemblaggio di runtime principale. Il runtime comprende intrinsecamente questo tipo e fornisce le funzionalità che gli sviluppatori si aspettano per le stringhe in .NET. La sua presenza è così critica per C # che se quel tipo non esiste il compilatore uscirà prima di tentare persino di analizzare una riga di codice. Quindi stringha un significato preciso e inequivocabile nel codice C #.

L'identificatore, Stringtuttavia, non ha alcun significato concreto in C #. È un identificatore che passa attraverso tutte le regole di ricerca del nome come Widget, Studentecc. Potrebbe legarsi alla stringa o potrebbe legarsi a un tipo in un altro assieme i cui scopi potrebbero essere completamente diversi da string. Peggio ancora, potrebbe essere definito in modo tale che il codice piaccia String s = "hello"; ha continuato a compilare.

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;
}

Il significato effettivo di Stringdipenderà sempre dalla risoluzione dei nomi. Ciò significa che dipende da tutti i file di origine nel progetto e da tutti i tipi definiti in tutti gli assiemi di riferimento. In breve, richiede un po 'di contesto per sapere cosa significa.

È vero che nella stragrande maggioranza dei casi Stringe stringsi legherà allo stesso tipo. Ma usare Stringsignifica ancora che gli sviluppatori stanno lasciando il loro programma all'interpretazione in luoghi in cui esiste una sola risposta corretta. Quando Stringsi lega al tipo sbagliato, può lasciare agli sviluppatori il debug per ore, archiviare bug nel team del compilatore e in generale perdere tempo che avrebbe potuto essere salvato utilizzando string.

Un altro modo per visualizzare la differenza è con questo esempio:

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

Molti sosterranno che, sebbene queste informazioni siano tecnicamente accurate, l'uso Stringè ancora valido perché è estremamente raro che una base di codice definisca un tipo di questo nome. O che quando Stringè definito è un segno di una base di codice errata.

[...]

Vedrai che Stringè definito per una serie di scopi completamente validi: aiutanti di riflessione, librerie di serializzazione, lexer, protocolli, ecc ... Per ognuna di queste librerie Stringvs. stringha conseguenze reali a seconda di dove viene usato il codice.

Quindi ricorda quando vedi il dibattito Stringvs. stringquesto riguarda la semantica, non lo stile. La scelta della stringa dà un significato nitido alla base di codice. Scegliere Stringnon è sbagliato ma sta lasciando la porta aperta alle sorprese in futuro.

Nota: ho copiato / incollato la maggior parte del post del blog per motivi di archiviazione. Ignoro alcune parti, quindi consiglio di saltare e leggere il post del blog, se puoi.