[c#] Qual è la differenza tra stringa e stringa in C #?


Answers

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

Come altri hanno notato, string è un alias per System.String . Compilano 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 la string e l' object , gli alias sono tutti 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 di tipo 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. (Confrontalo con VB, che consente i letterali DateTime e ha anche un alias.)

C'è una circostanza in cui è necessario utilizzare gli alias: quando si specifica esplicitamente il tipo sottostante di un enum. Per esempio:

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

Questo è solo il modo in cui le specifiche definiscono le dichiarazioni enum - la parte dopo i due punti deve essere la produzione di tipo integrale , che è un token di sbyte , byte , short , ushort , int , uint , long , ulong , char . .. a differenza di un tipo di produzione utilizzato dalle dichiarazioni variabili, ad esempio. Non indica altre differenze.

Infine, quando si tratta di usare: personalmente uso gli alias ovunque per l'implementazione, ma il tipo CLR per qualsiasi API. Non importa molto che usi in termini di implementazione: la coerenza tra la tua squadra è buona, ma a nessun altro interesserà. D'altra parte, è davvero importante che se si fa riferimento a un tipo in un'API, lo si fa in una lingua neutrale. Un metodo chiamato ReadInt32 non è ambiguo, mentre un metodo chiamato ReadInt richiede l'interpretazione. Il chiamante potrebbe utilizzare un linguaggio che definisce un alias per Int16 , ad esempio. I progettisti di framework .NET hanno seguito questo modello, con buoni esempi nelle BitConverter , BinaryReader e Convert .

Question

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 ?




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

  • Ho visto un certo numero di sviluppatori confusi, non sapendo se usare string o String nel loro codice. Perché in C # la stringa (una parola chiave) viene mappata esattamente su System.String (un tipo FCL), non vi è alcuna differenza e può essere utilizzato.
  • In C #, mappe lunghe a System.Int64 , ma in un linguaggio di programmazione diverso, long poteva mappare su Int16 o Int32 . In effetti, C ++ / CLI in realtà tratta come un Int32 . Qualcuno che legge il codice sorgente in una lingua potrebbe facilmente interpretare erroneamente l'intenzione del codice se fosse abituato a programmare in un linguaggio di programmazione diverso. In effetti, la maggior parte delle lingue non verrà trattata a lungo come una parola chiave e non verrà compilato 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 e il tipo System.Convert offre metodi come ToBoolean , ToInt32 , ToSingle e così via. Sebbene sia legale scrivere il seguente codice, la linea con float mi sembra molto innaturale, e non è ovvio che la linea 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 davvero ottimi punti. Tuttavia, non mi trovo a usare il consiglio di Jeffrey nel mio codice. Forse sono troppo bloccato nel mio mondo C # ma finisco per cercare di rendere il mio codice simile al codice quadro.




Non c'è alcuna differenza tra i due - string, tuttavia, sembra essere l'opzione preferita quando si considera il codice sorgente di altri sviluppatori.




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




System.String è la classe di stringa .NET - in C # la string è un alias per System.String - così in uso sono gli stessi.

Per quanto riguarda le linee guida, non mi sento troppo impantanato e uso solo quello che vuoi - ci sono cose più importanti nella vita e il codice sarà lo stesso comunque.

Se vi trovate a costruire sistemi dove è necessario specificare la dimensione degli interi che state usando e quindi tendete a usare Int16 , Int32 , UInt16 , UInt32 ecc. Allora potrebbe sembrare più naturale usare String - e quando ci si muove tra diversi .net lingue potrebbe rendere le cose più comprensibili - altrimenti userei string e int.




È una questione di convenzioni, davvero. "string" sembra più simile allo stile C / C ++. La convenzione generale è quella di utilizzare qualsiasi scorciatoia fornita dalla lingua scelta (int / Int per Int32). Questo vale anche per "oggetto" e "decimale".

Teoricamente questo potrebbe aiutare a portare il codice in qualche futuro standard a 64-bit in cui "int" potrebbe significare Int64, ma non è questo il punto, e mi aspetto che qualsiasi procedura guidata di aggiornamento modifichi qualsiasi riferimento "int" a "Int32" comunque solo per stai attento.




string e String sono identiche in tutti i modi (eccetto la "S" maiuscola). Non ci sono implicazioni di performance in entrambi i casi.

La string minuscola è preferita nella maggior parte dei progetti a causa dell'evidenziazione della sintassi




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

Originariamente ho iniziato a farlo anni fa, come da libri di CLR di Ritchie. Per me era logico che tutti i linguaggi CLR dovessero essere in grado di supportare l'insieme di tipi CLR, quindi l'utilizzo dei tipi CLR forniva un codice più chiaro e probabilmente più "riutilizzabile".

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

L'unico vero downer è che il completamento automatico utilizza il tipo C #, quindi ricomincio a digitare nuovamente i tipi generati automaticamente per specificare il tipo CLR.

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




Come dicono gli altri, sono uguali. Le regole StyleCop, per impostazione predefinita, impongono l'utilizzo della string come best practice per lo stile del codice C #, tranne quando si fa riferimento alle funzioni statiche System.String , come String.Format , String.Join , String.Concat , ecc.




C'è una differenza : non è possibile utilizzare String senza using System; in anticipo.




New answer after 6 years and 5 months (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.




La string minuscolo è un alias per System.String . Sono uguali in C# .

Si discute se utilizzare i tipi di sistema ( System.Int32 , System.String , ecc.) O gli C# aliases ( int , string , ecc.). Personalmente credo che dovresti usare gli C# aliases , ma questa è solo la mia preferenza personale.




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




Questo video di YouTube dimostra praticamente come si differenziano.

Ma ora per una lunga risposta testuale.

Quando parliamo di .NET ci sono due cose diverse una che è .NET framework e l'altra ci sono linguaggi ( C# , VB.NET ecc.) Che usano quel framework.

" System.String " alias "String" (maiuscola "S") è un tipo di dati framework .NET mentre "string" è un tipo di dati C# .

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

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.SByte , short: System.Int16 e così via

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

La prima cosa da evitare è usare confusamente uno di essi. Ma dal punto di vista delle migliori pratiche quando si fa la dichiarazione delle variabili è bene usare "string" (piccola "s") e quando lo si utilizza come nome di classe, viene preferito "String" (maiuscola "S").

Nel codice seguente il lato sinistro è una dichiarazione di variabile e ha dichiarato di usare "stringa". Sul lato destro stiamo chiamando un metodo in modo che "String" sia più ragionevole.

string s = String.ToUpper() ;



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




Links