Czy w języku C # powinienem używać łańcucha znaków.Empty lub String.Empty lub „”, aby zainicjalizować ciąg?

705

W języku C # chcę zainicjować wartość ciągu pustym ciągiem.

Jak mam to zrobić? Jaka jest właściwa droga i dlaczego?

string willi = string.Empty;

lub

string willi = String.Empty;

lub

string willi = "";

albo co?

Daniel Kreiseder
źródło
7
Zobacz także podobną dyskusję dla java: stackoverflow.com/questions/213985/...
harpo
39
na pewno lepiej jest jednak użyć String.IsNullOrEmpty (string myString)?
ZombieSheep,
3
Używam [string.IsNullOrWhiteSpace (stringvalue)] ... działa w .Net 4.0. Aby zainicjować, po prostu używam: [var text = "";] Prosty, czytelny i zajmuje najmniej czasu na
pisanie
61
Co ważniejsze, to przezabawna nazwa twojej zmiennej.
Arj
5
Interesuje mnie to, dlaczego istnieje nawet pusta nieruchomość. To jest miłe i wszystko, ale nie jest konieczne i kompletne musi.
MasterMastic,

Odpowiedzi:

807

Używaj tego, co Ty i Twój zespół uznacie za najbardziej czytelne.

Inne odpowiedzi sugerują, że za każdym razem tworzony jest nowy ciąg "". Nie jest to prawdą - ze względu na internowanie ciągów zostanie on utworzony albo raz na zespół, albo raz na AppDomain (lub ewentualnie raz dla całego procesu - nie jestem pewien z tej strony). Różnica ta jest znikoma - masowo, masowo nieistotna.

Jednak to, co uważasz za bardziej czytelne, to inna sprawa. Jest to subiektywne i będzie się różnić w zależności od osoby - dlatego sugeruję, abyś przekonał się, jak lubi większość ludzi w zespole i wszyscy zachowują spójność. Osobiście uważam, że ""łatwiej jest czytać.

Argument, że ""i " "są łatwo pomylić z siebie naprawdę nie myć się ze mną. O ile nie używasz czcionki proporcjonalnej (a ja nie współpracowałem z żadnymi programistami, którzy to robią), dość łatwo jest odróżnić.

Jon Skeet
źródło
75
Twoje oczy mogą cię oszukać, gdy spodziewasz się zobaczyć „”, możesz łatwo pomylić „” z „”. Dlatego łatwiej jest edytować coś, co napisał ktoś inny. Twój mózg nie ma z góry przyjętych pomysłów na temat tekstu, więc łatwiej jest wyłapać anonimowości.
tvanfosson
125
@tvanfosson: Więc czy ty (lub kolega) zostałeś ugryziony przez to jako błąd? Jestem podejrzliwy wobec tego rodzaju roszczeń, które nie spowodowałyby problemów. Używam „” od lat, nigdy nie popełniając błędu…
Jon Skeet,
34
Osobiście zawsze używałem String. Puste, używam wielkich liter „S”, ilekroć chcę użyć metody statycznej dla łańcucha, to tylko osobista preferencja, która pozwala mi odróżnić typ od zmiennej. Ale to tylko przeniesienie z używania StringUtils.EMPTY w pliku commons.lang z Java. Jednym z punktów zainteresowania jest to, że jestem prawie ślepy i to zdecydowanie pomaga mi w czytaniu.
Brett Ryan,
79
Dałeś mi inspirację do rozpoczęcia pracy w Times New Roman.
Justin Rusbatch
73
Z jakiegoś niejasnego powodu string.Emptynie jest stała . Oznacza to, że w wielu przypadkach, w których wymagana jest stała czasowa kompilacji, string.Emptynie jest nawet legalna. Obejmuje to case ""bloki w switchinstrukcjach, wartości domyślne parametrów opcjonalnych , parametry i właściwości w stosowaniu atrybutów oraz wiele innych sytuacji (pozostawionych czytelnikowi). Biorąc pod uwagę, że string.Emptyjest to niedozwolone w niektórych typowych sytuacjach, lepiej zastosować ""konwencję -w każdym innym miejscu.
Jeppe Stig Nielsen
375

Naprawdę nie ma różnicy z punktu widzenia wydajności i generowanego kodu. W testach wydajności poruszali się tam iz powrotem, między którymi jedno było szybsze w porównaniu do drugiego i tylko o milisekundy.

Patrząc na kod za kulisami, naprawdę nie widzisz żadnej różnicy. Jedyną różnicą jest IL, która string.Emptykorzysta z opcodu ldsfld i ""używa opcodu ldstr, ale string.Emptydzieje się tak tylko dlatego, że jest statyczna i obie instrukcje robią to samo. Jeśli spojrzysz na zespół, który jest produkowany, jest dokładnie taki sam.

Kod C #

private void Test1()
{
    string test1 = string.Empty;    
    string test11 = test1;
}

private void Test2()
{
    string test2 = "";    
    string test22 = test2;
}

Kod IL

.method private hidebysig instance void 
          Test1() cil managed
{
  // Code size       10 (0xa)
  .maxstack  1
  .locals init ([0] string test1,
                [1] string test11)
  IL_0000:  nop
  IL_0001:  ldsfld     string [mscorlib]System.String::Empty
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  stloc.1
  IL_0009:  ret
} // end of method Form1::Test1
.method private hidebysig instance void 
        Test2() cil managed
{
  // Code size       10 (0xa)
  .maxstack  1
  .locals init ([0] string test2,
                [1] string test22)
  IL_0000:  nop
  IL_0001:  ldstr      ""
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  stloc.1
  IL_0009:  ret
} // end of method Form1::Test2

Kod zestawu

        string test1 = string.Empty;
0000003a  mov         eax,dword ptr ds:[022A102Ch] 
0000003f  mov         dword ptr [ebp-40h],eax 

        string test11 = test1;
00000042  mov         eax,dword ptr [ebp-40h] 
00000045  mov         dword ptr [ebp-44h],eax 
        string test2 = "";
0000003a  mov         eax,dword ptr ds:[022A202Ch] 
00000040  mov         dword ptr [ebp-40h],eax 

        string test22 = test2;
00000043  mov         eax,dword ptr [ebp-40h] 
00000046  mov         dword ptr [ebp-44h],eax 
aBetterGamer
źródło
13
@PrateekSaluja: Aby zobaczyć IL, możesz użyć ildasm.exe, który jest dostarczany z Visual Studio. Aby zobaczyć diasemblację, użyj okna „Demontaż” w menu debugowania po trafieniu do punktu przerwania (działa również w kodzie wydania).
Thomas Bratt
1
Nienawidzę, że mam zamiar polecić ten produkt. ALE .. reflektor pozwala wybrać język podczas demontażu źródła, a IL jest opcją! ILDASM to po prostu przestarzałe uczucie ... Zespół narzędzi MS wydaje się nie szlifować ani wypuszczać dobrych narzędzi!
felickz
80

Najlepszy kod w ogóle nie ma kodu :

Podstawowa natura kodowania polega na tym, że naszym zadaniem jako programistów jest uznanie, że każda decyzja, którą podejmujemy, jest kompromisem. […] Zacznij od zwięzłości. Zwiększ inne wymiary zgodnie z wymaganiami testu.

W rezultacie, mniej kod jest lepszy kod: Wolę ""się string.Emptylub String.Empty. Te dwa są sześć razy dłuższe bez dodatkowej korzyści - z pewnością bez dodatkowej przejrzystości, ponieważ wyrażają dokładnie te same informacje.

Konrad Rudolph
źródło
1
ale w języku C # możemy po prostu powiedzieć string.IsNullOrWhitespace (s): p
felickz
31
Zgadzam się, że kod powinien być tak mały, jak to możliwe, ale ogólnie nie twierdzę, że mniej znaków to zawsze lepszy kod. Na przykład, jeśli chodzi o nazewnictwo zmiennych, rozsądna liczba znaków generalnie daje lepsze nazwy niż tylko użycie i i j.
Markus Meyer
3
@Markus To bardzo zależy: dla zmiennej pętli reprezentującej indeks i jest lepsza niż długa nazwa zmiennej. Zawsze bardziej preferowane są nawet bardziej ogólne, krótsze nazwy zmiennych, które przekazują te same informacje , w tej samej przejrzystości. Po prostu, aby wyrazić niezbędne informacje, potrzebujesz pewnej długości postaci i nie zaprzeczam temu (nikt nie jest).
Konrad Rudolph
2
@Konrad: i jest dobrą nazwą zmiennej tylko wtedy, gdy pętla jest mała i nie zawiera żadnych innych wskaźników. Ale zgadzam się, że jeśli coś. można powiedzieć bardziej zwięźle, przekazując te same informacje, które byłyby preferowane, tak jak w ciągu. Pusta / "" wielkość liter. Łańcuch Puste nie dodaje żadnej przejrzystości.
Markus Meyer
Dla mnie: string.Empty mówi, że ten ciąg jest i powinien być Pusty przez cały czas, podczas gdy „” mówi w momencie pisania, ten ciąg może być pusty, ale możesz go zmienić.
aeroson
54

Jedną różnicą jest to, że jeśli używasz switch-caseskładni, nie możesz pisać, case string.Empty:ponieważ nie jest to stała. DostajeszCompilation error : A constant value is expected

Spójrz na ten link, aby uzyskać więcej informacji: string-empty-versus-empty-quotes

Mentoliptus
źródło
22
To switchstwierdzenie jest bardzo dobrym przykładem. Ponadto, jeśli podasz parametr opcjonalny, np void MyMethod(string optional = "") { ... }. Nie będzie można go użyć string.Empty. A potem oczywiście, jeśli chcesz zdefiniować constpole lub zmienną lokalną, const string myString = "";znowu ""jest jedyną opcją. Gdyby tylko string.Emptybyło stałym polem, nie byłoby różnicy. Ale tak nie jest, więc w niektórych przypadkach musisz użyć "". Dlaczego więc nie korzystać ""cały czas?
Jeppe Stig Nielsen
5
To naprawdę mocny argument, ponieważ użycie string.Emptyuniemożliwia osiągnięcie spójności w bazie kodu: musisz użyć dwóch różnych bytów, aby wyrazić to samo. I dodać do listy rzeczy, których nie możesz zrobić: nie możesz używać string.Emptyz atrybutami .
Pragmateek,
2
Bardzo dobre punkty! Link jest zepsuty. Oto kopia treści: web.archive.org/web/20131230161806/http://kossovsky.net/…
ygoe
42

Wolałbym stringsię String. Wybierając się string.Emptyna ""to kwestia wyboru jednego i wystaje z niego. Zaletą używania string.Emptyjest to, że masz na myśli to, co masz na myśli, i nie kopiujesz przypadkowo znaków niedrukowalnych, jak "\x003"w twoim "".

Jimmy
źródło
101
Twierdziłbym, że jeśli przypadkowo kopiujesz znaki niedrukowalne do swojego kodu, masz większe problemy niż to pytanie;)
Jon Skeet
9
ASCII \ 003 okazuje się ogranicznikiem pola dla wiadomości B2B, z którymi współpracowałem :)
Jimmy,
7
(Sugeruję również unikanie ucieczki \ x, btw - zbyt trudno jest dostrzec różnicę między „\ x9Bad Compiler” i „\ x9Good Compiler”, które mają radykalnie różne wyniki!)
Jon Skeet
Osobiście wolę String niż String przy każdym wywołaniu metody statycznej na String. Jestem jednak prawie ślepy i jest to osobista preferencja, której nie narzucam nikomu.
Brett Ryan,
2
@ Jimmy Sure, ale rozmawialiśmy o pustym łańcuchu. Argument, który ""jest niebezpieczny, gdy kopiowanie / wklejanie jest nieważny, twierdzę, ponieważ nigdy nie kopiujesz / wklejasz pustego łańcucha. Oczywiście w przypadku innych łańcuchów zawsze należy pamiętać.
Timo,
22

Nie zamierzałem się wtrącać, ale widzę, że wyrzucano tutaj złe informacje.

Ja osobiście wolę string.Empty. To jest osobista preferencja i przychylam się do woli każdego zespołu, z którym pracuję na zasadzie indywidualnej.

Jak wspomnieli inni, nie ma żadnej różnicy między string.Emptyi String.Empty.

Ponadto jest to mało znany fakt, że użycie „” jest całkowicie dopuszczalne. Każde wystąpienie „” w innych środowiskach utworzy obiekt. Jednak .NET internalizuje swoje łańcuchy, więc przyszłe instancje wyciągną ten sam niezmienny ciąg z puli wewnętrznej, a każde uderzenie wydajności będzie znikome. Źródło: Brad Abrams .

John Rudy
źródło
20
Nie rozumiem, dlaczego „technicznie” każde wystąpienie „” stworzy obiekt. To nie tylko szansa, że ​​łańcuchy zostaną internowane - to w specyfikacji C #.
Jon Skeet
15

Osobiście wolę „”, chyba że istnieje uzasadniony powód do czegoś bardziej złożonego.

MidnightGun
źródło
13

String.Emptyi string.Emptysą równoważne. Stringto nazwa klasy BCL; stringto jego alias C # (lub skrót, jeśli chcesz). To samo co z Int32i int. Zobacz dokumenty, aby uzyskać więcej przykładów.

Jeśli chodzi ""o mnie, nie jestem do końca pewien.

Osobiście zawsze używam string.Empty.

Silviu Niculita
źródło
10

Prawie każdy programista będzie wiedział, co znaczy „”. Osobiście zetknąłem się z String.Empty po raz pierwszy i musiałem poświęcić trochę czasu na wyszukiwanie w Google, aby dowiedzieć się, czy naprawdę dokładnie takie same.

Jason Baker
źródło
3
Jest to publiczne ciąg znaków tylko do odczytu, a jego wartości to „” ... dlaczego miałoby się to zmienić?
Matthew Whited
5
Tęsknisz za stwierdzeniem @Jason. Skąd wiesz, co widzisz po raz pierwszy string.Empty? Czy wiesz, jaki ""był pierwszy raz?
David R Tribble
10

Ten temat jest dość stary i długi, więc przepraszam, jeśli takie zachowanie zostało wspomniane gdzie indziej. (I wskaż mi odpowiedź na to pytanie)

Znalazłem różnicę w zachowaniu kompilatora, jeśli używasz string.Emptylub cudzysłowu. Różnica pokazuje się, jeśli nie używasz zmiennej łańcuchowej zainicjowanej ciągiem znaków. Puste lub z podwójnymi cudzysłowami.

W przypadku inicjalizacji z string.Emptytym ostrzeżeniem kompilatora

CS0219 - The variable 'x' is assigned but its value is never used

nigdy nie jest emitowany, podczas gdy w przypadku inicjowania podwójnymi cudzysłowami pojawia się oczekiwany komunikat.

To zachowanie wyjaśniono w artykule Connect pod tym linkiem: https://connect.microsoft.com/VisualStudio/feedback/details/799810/c-warning-cs0219-not-reported-when-assign-non-constant-value

Zasadniczo, jeśli dobrze to zrozumiem, chcą pozwolić programistowi ustawić zmienną z wartością zwracaną funkcji do celów debugowania bez zawracania mu głowy ostrzeżeniem, a zatem ograniczają ostrzeżenie tylko w przypadku kosztownych przypisań i łańcucha. Puste nie jest stałą, ale polem.

Steve
źródło
1
Wierzę, że jesteś pierwszym, który wspomniał. Przeczytałem to pytanie kilka miesięcy temu i nie pamiętam tej różnicy, którą bym zrobił, gdyby został wspomniany.
Palec 30.04.16
2
Ciekawy. Pamiętaj, że var unused = "literal";kompilator może całkowicie zoptymalizować (usunąć) deklarację . Nie może powodować żadnych skutków ubocznych. Z drugiej strony var unused = MyClass.Member;nie można go całkowicie usunąć. To dlatego, że czytanie Membermoże mieć skutki uboczne. Jeśli Memberjest to właściwość statyczna z getakcesorium, jasne jest, że połączenie z modułem pobierającym musi zostać zachowane. Ale nawet jeśli Memberjest to pole statyczne, może wystąpić efekt uboczny, który może uruchomić konstruktor statyczny. Jasne, że taki sposób kodowania byłby zły . Ale potrzebujesz manekina do czytania Member.
Jeppe Stig Nielsen
9

Ten bardzo prosty test wykonałem przy użyciu następującej metody w aplikacji konsolowej:

private static void CompareStringConstants()
{
    string str1 = "";
    string str2 = string.Empty;
    string str3 = String.Empty;
    Console.WriteLine(object.ReferenceEquals(str1, str2)); //prints True
    Console.WriteLine(object.ReferenceEquals(str2, str3)); //prints True
}

To wyraźnie sugeruje, że wszystkie trzy zmienne mianowicie str1, str2i str3chociaż są inicjowane przy użyciu innej składni, wskazują dokładnie ten sam obiekt (o zerowej długości) w pamięci. Test wykonałem w aplikacji konsoli .NET 4.5. Więc wewnętrznie nie mają różnicy, a wszystko sprowadza się do wygody, której chcesz użyć jako programisty. To zachowanie klasy ciągów jest znane jako internowanie ciągów w .NET. Eric Lippert ma bardzo ładny blog tutaj opisujący tę koncepcję.

RBT
źródło
8

Dowolne z powyższych.

Jest wiele lepszych rzeczy do pontyfikatu. Jak na przykład kolor kory najlepiej pasuje do drzewa, myślę, że jest niejasny brąz z odcieniami mchu cielęcego.

Quibblesome
źródło
7

Zdecydowanie wolę String.Empty, oprócz innych powodów, aby upewnić się, że wiesz, co to jest i że nie usunąłeś przypadkowo treści, ale przede wszystkim w celu internacjonalizacji. Jeśli widzę ciąg znaków w cudzysłowie, zawsze muszę się zastanawiać, czy jest to nowy kod i należy go umieścić w tabeli ciągów. Więc za każdym razem, gdy kod jest zmieniany / sprawdzany, musisz szukać „czegoś w cudzysłowach” i tak, możesz odfiltrować puste ciągi znaków, ale mówię ludziom, że dobrą praktyką jest, aby nigdy nie wstawiać ciągów znaków w cudzysłowie, chyba że wiesz, że nie zostanie ono zlokalizowane .


źródło
7

Nikt nie wspominał, że w VisualStudio String jest kodowany kolorem inaczej niż string. Co jest ważne dla czytelności. Również małe litery są zwykle używane dla zmiennych i typów, nie jest to wielka sprawa, ale String.Empty jest stałą, a nie zmienną ani typem.

Dimitry
źródło
String.Empty nie jest stałą: patrz stackoverflow.com/questions/507923/… To tak naprawdę instancja klasy String, zgodnie z projektem. I kolorowanie zostało wspomniane wcześniej, choć nieco ukryte: stackoverflow.com/questions/263191/…
Michael
6

stringjest synonimem System.Stringtypu, są identyczne.

Wartości są również identyczne: string.Empty == String.Empty == ""

Nie chciałbym używać stałej znaków „” w kodzie, raczej string.Emptylub String.Empty- łatwiej zobaczyć co programista miał na myśli.

Pomiędzy stringi bardziej Stringlubię małe litery stringtylko dlatego, że pracowałem z Delphi przez wiele lat, a styl Delphi jest pisany małymi literami string.

Więc gdybym był twoim szefem, pisałbyś string.Empty

zendar
źródło
6

Chciałbym sprzyjać string.Emptynad String.Emptydlatego można go używać bez konieczności obejmują using System;w pliku.

Jeśli chodzi o zbieranie ""ciągu string.Emptyjest to osobiste preferencje i powinny być podejmowane przez zespół.

Andrzej
źródło
2
Jestem jedynym członkiem zespołu, jak zdecydować? Rzuć kostką?
Gqqnbig
1
Dla tych, którzy mogą się zastanawiać, jak można używać string.Emptystałej bez importowania using Systemprzestrzeni nazw - słowa kluczowe w C # po prostu przekonwertuj na ich w pełni kwalifikowaną nazwę, która obejmuje również przestrzeń nazw, zanim zostanie zapisana jako MSIL na wyjściu * .dll lub *. plik exe. Tak skutecznie string.Emptyzostaje zapisany System.String.Emptyprzez kompilator jak w MSIL. A ponieważ już wiesz, że jeśli podasz pełną nazwę typu, możesz pominąć importowanie przestrzeni nazw u góry pliku kodu.
RBT
5

Nie robię różnicy. Ten ostatni jest jednak najszybszy do wpisania :)


źródło
4

To nie ma znaczenia - są dokładnie takie same. Najważniejsze jest jednak, abyś był konsekwentny

ps Cały czas walczę z tego rodzaju „co jest właściwe”.

Calanus
źródło
1
We współczesnym świecie „konsekwentny” oznacza konsekwentny we wszystkich zespołach na całym świecie, co jest jednym z celów StackOverflow. Jeśli mogę zasugerować, użyjmy String.Empty.
Pavel Radzivilovsky
1
Niektóre języki nie mają stałej pustej, a wszystkie języki, o których mogę myśleć, pozwalają na ciąg znaków „” o zerowej długości. Głosuję więc za „” za spójność z innymi językami. :)
TomXP411
4

Jest to całkowicie preferencja stylu kodu, rób, jak .NET obsługuje ciągi znaków. Oto moje opinie :)

Przy dostępie do statycznych metod, właściwości i pól zawsze używać nazw BCL Typ: String.Emptylub Int32.TryParse(...)lubDouble.Epsilon

Zawsze używam słów kluczowych C # przy deklarowaniu nowych instancji: int i = 0;lubstring foo = "bar";

Rzadko używam niezadeklarowanych literałów łańcuchowych, ponieważ lubię mieć możliwość skanowania kodu w celu połączenia ich w nazwane stałe wielokrotnego użytku. Kompilator i tak zastępuje stałe literałami, więc jest to raczej sposób na uniknięcie magicznych ciągów / liczb i nadanie im trochę więcej znaczenia dzięki nazwie. Plus zmiana wartości jest łatwiejsza.

McKamey
źródło
3

Używam trzeciego, ale z pozostałych dwóch pierwszy wydaje się mniej dziwny. string jest aliasem dla String, ale odczuwanie ich w zadaniu jest oderwane.

cokół
źródło
3

Każde z dwóch pierwszych byłoby dla mnie do zaakceptowania. Unikałbym tego ostatniego, ponieważ stosunkowo łatwo jest wprowadzić błąd, umieszczając odstęp między cudzysłowami. Ten konkretny błąd byłby trudny do znalezienia przez obserwację. Zakładając brak literówek, wszystkie są semantycznie równoważne.

[EDYTOWAĆ]

Ponadto, warto zawsze użyć jednej stringlub Stringdla spójności, ale to tylko moje zdanie.

tvanfosson
źródło
Zgadzam się z tą uwagą, ale nadal żyję niebezpiecznie, kiedy jestem leniwy. W każdym razie nie sądzę, że mam okazję napisać kod, który używa łańcucha przed przypisaniem go poza deklaracją zmiennej. W rzeczywistości denerwuje mnie to, że mimo ryzyka muszę w ogóle inicjalizować ciągi.
EnocNRoll - AnandaGopal Pardue
3

Osobiście byłem świadkiem „” powodujących (niewielkie) problemy dwukrotnie. Kiedyś był to błąd młodszego programisty, który był nowy w programowaniu zespołowym, a drugi to zwykła literówka, ale faktem jest ciąg znaków. Puste uniknęłoby obu problemów.

Tak, jest to w dużej mierze wezwanie do osądu, ale gdy język daje wiele sposobów robienia rzeczy, zwykle skłaniam się ku temu, który ma największy nadzór kompilatora i najsilniejsze wymuszanie czasu kompilacji. To nie jest „”. Chodzi o wyrażanie konkretnych intencji.

Jeśli wpiszesz string.EMpty lub Strng.Empty, kompilator poinformuje cię, że zrobiłeś to źle. Natychmiast. Po prostu się nie skompiluje. Jako programista powołujesz się na konkretną intencję, że kompilator (lub inny programista) nie może w żaden sposób źle interpretować, a gdy zrobisz to źle, nie możesz stworzyć błędu.

Jeśli wpiszesz „”, gdy masz na myśli „” lub odwrotnie, kompilator z radością zrobi to, co mu kazałeś. Inny programista może, ale nie musi, poznać twoją konkretną intencję. Błąd został utworzony.

Na długo przed string.Empty był rzeczą, której użyłem standardowej biblioteki, która zdefiniowała stałą EMPTY_STRING. Nadal używamy tej stałej w instrukcjach case, w których string.Empty jest niedozwolone.

O ile to możliwe, włącz kompilator, aby działał dla Ciebie i wyeliminuj możliwość błędu ludzkiego, bez względu na to, jak mały. IMO przebija „czytelność”, jak cytowali inni.

Specyfika i wymuszanie czasu kompilacji. To jest na obiad.

RhinoTX
źródło
3

Używam „”, ponieważ w moim kodzie będzie miał wyraźnie żółty kolor ... z jakiegoś powodu String.Empty jest cały biały w moim motywie Visual Studio Code. I uważam, że to dla mnie najważniejsze.

5argon
źródło
2

Kompilator powinien uczynić je takimi samymi na dłuższą metę. Wybierz standard, aby kod był łatwy do odczytania i trzymaj się go.

Chris Marasti-Georg
źródło
2

Właśnie patrzyłem na jakiś kod i to pytanie przyszło mi do głowy, które czytałem już jakiś czas. Z pewnością jest to kwestia czytelności.

Rozważ następujący kod C # ...

(customer == null) ? "" : customer.Name

vs

(customer == null) ? string.empty : customer.Name

Osobiście uważam to drugie za mniej dwuznaczne i łatwiejsze do odczytania.

Jak zauważyli inni, rzeczywiste różnice są znikome.

Remotec
źródło
1

Myślę, że to drugie jest „właściwe”, ale szczerze mówiąc, nie sądzę, żeby miało to znaczenie. Kompilator powinien być wystarczająco inteligentny, aby skompilować dowolny z tych dokładnie do tego samego kodu bajtowego. Sam używam „”.

Mag
źródło
1

Chociaż różnica jest bardzo, BARDZO mała, różnica wciąż istnieje.

1) „” tworzy obiekt, a String.Empty nie. Ale ten obiekt zostanie utworzony jeden raz i będzie później przywoływany z puli ciągów, jeśli masz inny kod w kodzie.

2) Ciąg znaków i ciąg znaków są takie same, ale zalecałbym użycie String.Empty (jak również String.Format, String.Copy itp.), Ponieważ notacja kropkowa wskazuje klasę, a nie operator, a klasa zaczynająca się od dużej litery jest zgodna z Standardy kodowania C #.

użytkownik34577
źródło
1
string.Empty is "", sprawdź źródło
dss539,
1

Na http://blogs.msdn.com/b/brada/archive/2003/04/22/49997.aspx :

Jak sugeruje Dawid, różnice między String.Emptyi ""są dość małe, ale jest różnica. ""faktycznie tworzy obiekt, prawdopodobnie zostanie wyciągnięty z wewnętrznej puli ciągów znaków, ale nadal ... podczas gdy String.Emptynie tworzy żadnego obiektu ... więc jeśli naprawdę szukasz ostatecznej wydajności pamięci, sugeruję String.Empty. Należy jednak pamiętać, różnica jest tak TRIVAL będzie jak nigdy zobaczyć go w kodzie ...
jak na System.String.Emptylub string.Emptylub String.Empty... mój poziom opieki jest niski ;-)

sergiol
źródło
1
Ten post na blogu MSDN miał miejsce w 2003 roku ... czy jesteś pewien, że nadal dotyczy to najnowszych wersji .NET ?!
Carsten Schütte
@ CarstenSchütte: Wydaje mi się, że taka funkcja nie ma wiele zmienić ... a jeśli tak, to w Internecie było trochę szumu.
sergiol
3
@sergiol Jeśli pole jest bardziej wydajne niż literał, oznacza to jednoznacznie błąd wydajności. Mamy więc nadzieję, że zostanie to już naprawione.
Konrad Rudolph
1

Pusty ciąg jest jak pusty zestaw, po prostu nazwa, którą wszyscy używają do wywołania "" . Również w językach formalnych ciągi utworzone z alfabetu o zerowej długości są nazywane ciągiem pustym. Zarówno zestaw, jak i łańcuch mają dla niego specjalny symbol. Pusty ciąg: ε i pusty zestaw: ∅. Jeśli chcesz porozmawiać o tym łańcuchu o zerowej długości, nazwiesz go pustym ciągiem, aby wszyscy wiedzieli dokładnie, o czym mówisz. Teraz, jeśli nazwiesz go pustym ciągiem, dlaczego nie użyć string.Emptyw kodzie, jego zamiary są wyraźne. Minusem jest to, że nie jest stała i dlatego nie jest dostępna wszędzie, jak w atrybutach. (Z pewnych przyczyn technicznych nie jest stała, zobacz źródło odniesienia).

Wouter
źródło
0

Wolę, ""ponieważ jest krótszy i String.Emptyrozwiązuje problem, który nie istnieje.

Anders Lindén
źródło