Przykład ( zwróć uwagę na przypadek ):

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

Jakie są zasady korzystania z każdego z nich? A jakie są różnice?

stringto alias w języku C # dla System.String.
Więc technicznie nie ma różnicy. To jak int vs. System.Int32 .

Jeśli chodzi o wytyczne, ogólnie zaleca się korzystanie z niego za stringkażdym razem, gdy odwołujesz się do obiektu.

na przykład

string place = "world";

Podobnie, myślę, że ogólnie zaleca się stosowanie, Stringjeśli chcesz odnieść się konkretnie do klasy.

na przykład

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

Jest to styl, który Microsoft używa w swoich przykładach .

Wygląda na to, że wskazówki w tym obszarze mogły ulec zmianie, ponieważ StyleCop wymusza teraz stosowanie aliasów specyficznych dla języka C #.

Dla kompletności, oto zrzut mózgu powiązanych informacji ...

Jak zauważyli inni, stringjest to pseudonim System.String. Kompilują się do tego samego kodu, więc w czasie wykonywania nie ma żadnej różnicy. To tylko jeden z aliasów w C #. Pełna lista to:

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

Oprócz stringi objectaliasy mają wszystkie typy wartości. decimaljest typem wartości, ale nie pierwotnym typem w CLR. Jedynym prymitywnym typem, który nie ma aliasu, jest System.IntPtr.

W specyfikacji aliasy typu wartości są znane jako „typy proste”. Literały mogą być użyte dla stałych wartości każdego prostego typu; żadne inne typy wartości nie mają dosłownych postaci. (Porównaj to z VB, który pozwala na DateTimeliterały i ma też alias.)

Jest jeszcze jedna okoliczność, w której ma używać aliasów: kiedy wyraźnie określający typ podstawowy enum jest. Na przykład:

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

To tylko kwestia sposobu spec definiuje enum deklaracji - część po dwukropku musi być integralną typu produkcję, która jest jednym wyrazem sbyte, byte, short, ushort, int, uint, long, ulong, char... w przeciwieństwie do typu produkcji, jak używane na przykład w deklaracjach zmiennych. Nie wskazuje to na żadną inną różnicę.

Wreszcie, jeśli chodzi o użycie: osobiście używam aliasów wszędzie do implementacji, ale typ CLR dla dowolnych interfejsów API. Naprawdę nie ma to większego znaczenia, którego używasz pod względem implementacji - spójność w zespole jest miła, ale nikogo to nie obchodzi. Z drugiej strony naprawdę ważne jest, aby odwoływać się do typu w interfejsie API, robiąc to w sposób neutralny językowo. Wywołana metoda ReadInt32jest jednoznaczna, podczas gdy nazwana metoda ReadIntwymaga interpretacji. Dzwoniący może na przykład używać języka, który definiuje intalias Int16. Projektanci .NET Framework podążały tego wzoru, dobre przykłady bycia w BitConverter, BinaryReaderi Convertklas.

Stringoznacza System.Stringi jest to .NET Framework. stringto alias w języku C # dla System.String. Oba są kompilowane System.Stringw języku IL (Intermediate Language), więc nie ma różnicy. Wybierz, co lubisz i używaj tego. Jeśli kodujesz w języku C #, wolałbym, stringponieważ jest to alias typu C # i dobrze znany przez programistów C #.

Mogę powiedzieć to samo o ( int, System.Int32) itp.

Najlepsza odpowiedź, jaką kiedykolwiek słyszałem o używaniu podanych typów aliasów w C #, pochodzi od Jeffreya Richtera w jego książce CLR Via C # . Oto jego 3 powody:

• Widziałem wielu deweloperów zdezorientowany, nie wiedząc, czy użyć ciąg lub ciąg w kodzie. Ponieważ w języku C # ciąg (słowo kluczowe) jest dokładnie odwzorowany na System.String (typ FCL), nie ma różnicy i można go użyć.
• W języku C # długie mapy na System.Int64 , ale w innym języku programowania, długie mogą być mapowane na Int16 lub Int32 . W rzeczywistości C ++ / CLI faktycznie traktuje długo jak Int32 . Ktoś czytający kod źródłowy w jednym języku mógłby łatwo błędnie zinterpretować intencję kodu, gdyby był przyzwyczajony do programowania w innym języku programowania. W rzeczywistości większość języków nie traktuje długo jako słowa kluczowego i nie skompiluje kodu, który go używa.
• FCL ma wiele metod, które mają nazwy typów jako część nazw metod. Na przykład typ BinaryReader oferuje metody takie jak ReadBoolean , ReadInt32 , ReadSingle itp., A typ System.Convert oferuje metody takie jak ToBoolean , ToInt32 , ToSingle i tak dalej. Chociaż napisanie następującego kodu jest legalne, wiersz z float wydaje mi się bardzo nienaturalny i nie jest oczywiste, czy wiersz jest poprawny:

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

Więc masz to. Myślę, że to są naprawdę dobre punkty. Nie używam jednak rad Jeffreya we własnym kodzie. Być może jestem zbyt utknięty w moim świecie C #, ale w końcu staram się, aby mój kod wyglądał jak kod frameworka.

stringjest zastrzeżonym słowem, ale Stringjest tylko nazwą klasy. Oznacza to, że sam stringnie może być użyty jako nazwa zmiennej.

Jeśli z jakiegoś powodu chcesz zmiennej o nazwie string , zobaczysz tylko pierwszą z tych kompilacji:

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

Jeśli naprawdę potrzebujesz nazwy zmiennej o nazwie string , możesz użyć jej @jako prefiksu:

StringBuilder @string = new StringBuilder();

Kolejna krytyczna różnica: przepełnienie stosu wyróżnia je inaczej.

Jest jeszcze jedna różnica - nie można używać Stringbez using System;wcześniej.

Zostało to omówione powyżej; nie możesz jednak używać stringw refleksji; musisz użyć String.

System.Stringjest klasą ciągów .NET - w C # stringjest aliasem System.String- więc w użyciu są takie same.

Jeśli chodzi o wytyczne, nie ugrzęznę zbytnio i po prostu używam tego, na co masz ochotę - w życiu są ważniejsze rzeczy, a kod i tak będzie taki sam.

Jeśli znajdziecie się systemy, w których konieczne jest budynek określić wielkość liczb całkowitych, którego używasz, a więc mają tendencję do używania Int16, Int32, UInt16, UInt32itd. To może wyglądać bardziej naturalnie używać String- i podczas poruszania się między różnymi językami .net to może uczynić rzeczy bardziej zrozumiałymi - w przeciwnym razie użyłbym łańcucha i int.

Wolę .NETtypy pisane wielkimi literami (zamiast aliasów) ze względu na formatowanie. Te .NETtypy są barwione takie same jak innych typów obiektów (typy wartości są odpowiednie obiekty, mimo wszystko).

Słowa kluczowe warunkowe i kontrolne (jak if, switchi return) są pisane małymi literami i mają kolor ciemnoniebieski (domyślnie). I wolałbym nie mieć niezgodności w użyciu i formacie.

Rozważać:

String someString; 
string anotherString; 

stringi Stringsą identyczne pod każdym względem (oprócz wielkich liter „S”). Tak czy inaczej, nie ma to wpływu na wydajność.

Małe litery stringsą preferowane w większości projektów ze względu na wyróżnianie składni

C # to język używany razem z CLR.

string jest typem w C #.

System.String jest typem w CLR.

Gdy użyjesz C # wraz z CLR stringzostanie zamapowany na System.String.

Teoretycznie można zaimplementować kompilator C #, który wygenerował kod bajtowy Java. Rozsądnym Realizacja tego kompilatora najprawdopodobniej na mapie string, aby java.lang.Stringw celu współdziałania z biblioteki uruchomieniowym Java.

Ten film na YouTube pokazuje praktycznie, jak się różnią.

Ale teraz długa odpowiedź tekstowa.

Kiedy mówimy o .NETistnieją dwie różne rzeczy jeden jest .NETramowy i drugi są języki ( C#, VB.NETetc), które wykorzystują te ramy.

„ System.String„ aka ”„ String ”(wielkie„ S ”) jest .NETramowym typem danych, a„ string ”to C#typ danych.

W skrócie „String” to alias (to samo, co nazywa się różnymi nazwami) „string”. Tak więc technicznie obie poniższe instrukcje kodu dają to samo wyjście.

String s = "I am String";

lub

string s = "I am String";

W ten sam sposób istnieją aliasy dla innych typów danych c #, jak pokazano poniżej: -

Obiekt System.Object, string: System.String, bool: System.Booleanbajt: System.Byte, sbyte: System.SBytekrótka: System.Int16i tak dalej

Teraz pytanie za milion dolarów z punktu widzenia programisty Więc kiedy używać „String” i „string”?

Pierwszą rzeczą, aby uniknąć zamieszania, używaj jednego z nich konsekwentnie. Ale z punktu widzenia najlepszych praktyk, kiedy robisz deklarację zmiennej, dobrze jest używać „łańcucha” (małych „s”), a gdy używasz go jako nazwy klasy, preferowany jest „Łańcuch” (wielkie „S”).

W poniższym kodzie lewa strona jest deklaracją zmiennej i zadeklarowana za pomocą „łańcucha”. Po prawej stronie wywołujemy metodę, aby „String” był bardziej sensowny.

string s = String.ToUpper() ;

Małe litery stringto pseudonim System.String. Są takie same w C#.

Jest to debata nad tym, czy należy użyć typów systemów ( System.Int32, System.Stringetc.) rodzaje lub C# aliases( int, stringitp). Osobiście uważam, że powinieneś skorzystać C# aliases, ale to tylko moje osobiste preferencje.

stringjest tylko pseudonimem dla System.String. Kompilator potraktuje je identycznie.

Jedyną praktyczną różnicą jest podświetlanie składni, o czym wspominasz, i że musisz pisać, using Systemjeśli używasz String.

Oba są takie same. Ale z perspektywy wytycznych kodowania lepiej jest używać stringzamiast String. Tego właśnie używają programiści. np. zamiast używać Int32używamy intjako intalias doInt32

Do Twojej wiadomości „Ciąg słów kluczowych jest po prostu aliasem dla predefiniowanej klasy System.String”. - Specyfikacja języka C # 4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

Jak mówią inni, są tacy sami. Zasady StyleCop domyślnie wymusi na użycie stringjako kodu C # stylu najlepszych praktyk, z wyjątkiem gdy przedstawieniu System.Stringfunkcje statyczne, takie jak String.Format, String.Join, String.Concatitp ...

Nowa odpowiedź po 6 latach i 5 miesiącach (zwlekanie).

Chociaż stringjest zarezerwowanym słowem kluczowym C #, które zawsze ma stałe znaczenie, Stringjest zwykłym identyfikatorem, który może odnosić się do czegokolwiek. W zależności od elementów bieżącego typu bieżąca przestrzeń nazw oraz zastosowane usingdyrektywy i ich umiejscowienie Stringmogą być wartością lub typem innym niż global::System.String.

Podam dwa przykłady, w których usingdyrektywy nie pomogą .

Po pierwsze, kiedy Stringjest wartością bieżącego typu (lub zmiennej lokalnej):

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

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

Powyższe nie zostanie skompilowane, ponieważ IEnumerable<>nie ma wywołanego elementu niestatycznego Formati nie stosuje się żadnych metod rozszerzenia. W powyższym przypadku nadal może być możliwe użycie Stringw innych kontekstach, w których typ jest jedyną możliwością składniową. Na przykład String local = "Hi mum!";może być OK (w zależności od przestrzeni nazw i usingdyrektyw).

Gorzej: powiedzenie String.Concat(someSequence)prawdopodobnie (w zależności od usings) przejdzie na metodę rozszerzenia Linq Enumerable.Concat. Nie przejdzie do metody statycznej string.Concat.

Po drugie, kiedy Stringjest inny typ , zagnieżdżony w bieżącym typie:

class MyPiano
{
  protected class String
  {
  }

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

Żadna instrukcja w Examplemetodzie się nie kompiluje. Tutaj Stringzawsze jest piano ciąg , MyPiano.String. Nie istnieje na nim żaden element członkowski ( staticani nie Formatjest on dziedziczony z jego klasy podstawowej). A wartości "Goodbye"nie można na nią przeliczyć.

Korzystanie z typów System ułatwia przenoszenie między C # i VB.Net, jeśli lubisz takie rzeczy.

W przeciwieństwie do tego, co wydaje się być powszechną praktyką wśród innych programistów, wolę bardziej Stringniż stringtylko po to, aby podkreślić fakt, że Stringjest to typ odniesienia, jak wspomniał Jon Skeet.

stringto alias (lub skrót) z System.String. To znaczy, pisząc na stringmyśli, mieliśmy na myśli System.String. Możesz przeczytać więcej na stronie think link: „string” to alias / stenografia System.String.

Chciałbym tylko dodać to do odpowiedzi lfousts z książki Ritchers:

Specyfikacja języka C # stanowi: „Ze względu na styl, użycie słowa kluczowego jest preferowane zamiast używania pełnej nazwy typu systemu”. Nie zgadzam się ze specyfikacją języka; Wolę używać nazw typów FCL i całkowicie unikać pierwotnych nazw typów. W rzeczywistości chciałbym, aby kompilatory nawet nie oferowały nazw typów pierwotnych i zmusiły programistów do używania zamiast nich nazw typów FCL. Oto moje powody:

• Widziałem wielu deweloperów zdezorientowany, nie wiedząc, czy użyć ciąg lub ciąg w kodzie. Ponieważ w łańcuchu C # (słowo kluczowe) mapuje się dokładnie na System.String (typ FCL), nie ma żadnej różnicy i można go użyć. Podobnie słyszałem, jak niektórzy programiści mówili, że int reprezentuje 32-bitową liczbę całkowitą, gdy aplikacja działa w 32-bitowym systemie operacyjnym i że reprezentuje 64-bitową liczbę całkowitą, gdy aplikacja działa w 64-bitowym systemie operacyjnym. To stwierdzenie jest absolutnie fałszywe: w języku C # int zawsze mapuje na System.Int32 , a zatem reprezentuje 32-bitową liczbę całkowitą niezależnie od systemu operacyjnego, na którym działa kod. Jeśli programiści skorzystalibyInt32 w swoim kodzie, to potencjalne zamieszanie również zostaje wyeliminowane.

• W języku C # długie mapy na System.Int64 , ale w innym języku programowania, długie mogą być mapowane na Int16 lub Int32 . W rzeczywistości C ++ / CLI długo traktuje jak Int32 . Ktoś czytający kod źródłowy w jednym języku mógłby łatwo błędnie zinterpretować intencję kodu, gdyby był przyzwyczajony do programowania w innym języku programowania. W rzeczywistości większość języków nie traktuje długo jako słowa kluczowego i nie skompiluje kodu, który go używa.

• FCL ma wiele metod, które mają nazwy typów jako część nazw metod. Na przykład typ BinaryReader oferuje metody takie jak ReadBoolean , ReadInt32 , ReadSingle itp., A typ System.Convert oferuje metody takie jak ToBoolean , ToInt32 , ToSingle i tak dalej. Chociaż napisanie następującego kodu jest legalne, wiersz z float wydaje mi się bardzo nienaturalny i nie jest oczywiste, czy wiersz jest poprawny:

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

• Wielu programistów używających wyłącznie języka C # ma tendencję do zapominania, że ​​inne języki programowania mogą być używane przeciwko CLR, i dlatego z tego powodu do kodu biblioteki klas wkradają się organizmy C #. Na przykład Microsoft FCL jest prawie wyłącznie napisany w języku C # i deweloperów w zespole FCL teraz wprowadzono metody do biblioteki takiego jak Array „s GetLongLength , która zwraca Int64 wartość, która jest długo w C #, ale nie w innych językach (takich jak C ++ / CLI). Innym przykładem jest System.Linq.Enumerable jest LongCount metodą.

Nie otrzymałem jego opinii, zanim przeczytałem cały akapit.

String ( System.String) to klasa w bibliotece klas podstawowych. string (małe litery) to zarezerwowana praca w C #, która jest aliasem dla System.String. Int32 vs int jest podobną sytuacją Boolean vs. bool. Te słowa kluczowe specyficzne dla języka C # umożliwiają deklarowanie prymitywów w stylu podobnym do C.

Stringnie jest słowem kluczowym i może być używany jako identyfikator, natomiast stringjest słowem kluczowym i nie może być używany jako identyfikator. I z punktu widzenia funkcji oba są takie same.

To naprawdę kwestia konwencji. stringwygląda bardziej jak styl C / C ++. Ogólna konwencja polega na korzystaniu ze skrótów udostępnionych przez wybrany język (int / Int dla Int32). Dotyczy to również „obiektu” decimal.

Teoretycznie może to pomóc w przeniesieniu kodu do jakiegoś przyszłego standardu 64-bitowego, w którym może oznaczać „int” Int64, ale nie o to chodzi, i spodziewałbym się, że każdy kreator aktualizacji zmieni wszelkie intodniesienia do, Int32po prostu, aby był bezpieczny.

Spóźniam się na imprezę: używam typów CLR w 100% przypadków (cóż, z wyjątkiem sytuacji, gdy zmuszony jestem używać typu C #, ale nie pamiętam, kiedy to był ostatni raz).

Pierwotnie zacząłem robić to lata temu, zgodnie z książkami CLR autorstwa Ritchie. Miałem dla mnie sens, że wszystkie języki CLR ostatecznie muszą być w stanie obsługiwać zestaw typów CLR, więc użycie tych typów CLR zapewniło jaśniejszy i prawdopodobnie bardziej „wielokrotnego użytku” kod.

Teraz, gdy robię to od lat, jest to nawyk i podoba mi się ubarwienie, które VS pokazuje dla typów CLR.

Jedynym minusem jest to, że autouzupełnianie używa typu C #, więc kończę przepisywanie automatycznie generowanych typów w celu określenia typu CLR.

Również teraz, gdy widzę „int” lub „string”, wygląda mi to naprawdę źle, tak jak patrzę na kod C z 1970 roku.

Nie ma różnicy.

Słowo kluczowe C # stringodwzorowuje na typ .NET System.String- jest to alias, który utrzymuje konwencje nazewnictwa języka.

Podobnie intmapy do System.Int32.

Cytat na ten temat z książki Daniela Solisa .

Wszystkie predefiniowane typy są mapowane bezpośrednio na podstawowe typy .NET. Nazwy typu C # (ciąg znaków) są po prostu aliasami dla typów .NET (String lub System.String), więc używanie nazw .NET działa poprawnie składniowo, chociaż jest to odradzane. W programie C # powinieneś używać nazw C # zamiast nazw .NET.

ciąg jest słowem kluczowym i nie można użyć łańcucha jako identyfikatora.

Łańcuch nie jest słowem kluczowym i można go użyć jako identyfikatora:

Przykład

string String = "I am a string";

Słowo kluczowe string jest pseudonimem System.Stringoprócz problemu ze słowem kluczowym, oba są dokładnie równoważne.

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

Tak, to nie jest różnica między nimi, podobnie jak booli Boolean.

@JaredPar (twórca kompilatora C # i płodny użytkownik SO!) Napisał świetny post na blogu na ten temat. Myślę, że warto się tutaj podzielić. To miłe spojrzenie na nasz temat.

stringvs. Stringnie jest debatą stylową

[...]

Słowo kluczowe stringma konkretne znaczenie w języku C #. Jest to typ, System.Stringktóry istnieje w podstawowym zestawie wykonawczym. Środowisko wykonawcze w pełni rozumie ten typ i zapewnia możliwości, których twórcy oczekują od ciągów w .NET. Jego obecność jest tak ważna dla C #, że jeśli ten typ nie istnieje, kompilator zakończy działanie przed próbą nawet parsowania linii kodu. Stąd stringma precyzyjne, jednoznaczne znaczenie w kodzie C #.

Identyfikator Stringnie ma jednak konkretnego znaczenia w języku C #. Jest to identyfikator, który przechodzi przez wszystkie reguły wyszukiwania nazw jako Widget, Studentitp. Może wiązać się z łańcuchem lub z innym typem zestawu, którego cele mogą być zupełnie inne niż string. Co gorsza, można go zdefiniować w taki sposób, jak kod String s = "hello"; kontynuował kompilację.

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

Rzeczywiste znaczenie Stringzawsze będzie zależeć od rozpoznawania nazw. Oznacza to, że zależy to od wszystkich plików źródłowych w projekcie i wszystkich typów zdefiniowanych we wszystkich zestawach, do których istnieją odniesienia. Krótko mówiąc, potrzeba sporo kontekstu, aby wiedzieć, co to znaczy.

To prawda, że w zdecydowanej większości przypadków Stringi stringzwiąże się z tego samego typu. Ale używanie Stringnadal oznacza, że ​​programiści pozostawiają swój program do interpretacji w miejscach, gdzie jest tylko jedna poprawna odpowiedź. Kiedy Stringwiąże się z niewłaściwym typem, może programistom debugować godzinami, zgłaszać błędy w zespole kompilatora i generalnie marnować czas, który można by zaoszczędzić, używając string.

Innym sposobem na zwizualizowanie różnicy jest użycie tej próbki:

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

Wielu będzie argumentować, że chociaż informacje te są technicznie dokładne, używanie Stringjest w porządku, ponieważ niezwykle rzadko podstawa kodu definiuje typ tej nazwy. Lub, gdy Stringjest zdefiniowany, jest to znak złej bazy kodu.

[...]

Zobaczysz, że Stringjest zdefiniowany dla szeregu całkowicie ważnych celów: pomocników refleksji, bibliotek serializacji, leksykonów, protokołów itp. Dla każdej z tych bibliotek Stringvs. stringma realne konsekwencje w zależności od tego, gdzie jest używany kod.

Więc pamiętaj, kiedy widzisz debatę Stringkontra vs. stringdotyczy semantyki, a nie stylu. Wybór ciągu nadaje wyraźne znaczenie twojej bazie kodu. Wybór Stringnie jest zły, ale pozostawia otwarte drzwi dla niespodzianek w przyszłości.

Uwaga: skopiowałem / wkleiłem większość postów na blogu z przyczyn archiwalnych. Ignoruję niektóre części, więc jeśli to możliwe , polecam pominąć i przeczytać post na blogu .