Podczas czytania książki na C#, natrafiłem na kod, który używa @ do "przeciążenia" lub użyj słowa kluczowego C# jako identyfikatora. Zgaduję, że to nie jest dobra praktyka, ponieważ prowadzi do niejednoznaczności. Czy mam rację, myśląc o tym, czy są chwile, w których powinno się to stosować?Najlepsze praktyki dotyczące używania @ w C#
Rzeczywiście, prawie zawsze warto tego unikać. Główny czas może być przydatny, gdy mamy do czynienia z biblioteką zewnętrzną (z innego języka), która ma klasę/etc, która jest słowem kluczowym C#, ale przyznaję, że mam nigdy nie miałam problemu z w rzeczywistości. Pomaga to, że C# pozwala na zmianę nazw argumentów metod podczas przesłaniania/implementowania interfejsów, aby uniknąć jednego wspólnego zestawu przypadków.
Innym (prawdopodobnie leniwym) zastosowaniem jest generowanie kodu; jeśli zawsze dodajesz pola/zmienne/etc z @theName, to nie musisz się martwić o specjalne przypadki. Osobiście po prostu sprawdzam krzyżowo listę słów kluczowych/kontekstowych słów kluczowych w języku C# i dodam coś takiego jak podkreślenie.
Inne użycie symbolu @ (dosłowne ciągi znaków) jest @ "znacznie bardziej użyteczne".
Mam tylko używany i widać go stosować tylko struny, jak:
string [email protected]"some funny name";
Wydaje mi się, że jest bardziej użyteczny, gdy ciąg zawiera \, więc nie trzeba go uciec. –
Nigdy nie wiedział o tym, ale z tego co mówisz bym go uniknąć.
Jedyny przypadek, w którym używam @ w języku C#, dotyczy wstępnie sformatowanych ciągów.
@"String\no\need\to\escape\slashes"
Myślę, że chodziło o backslashes –
Rzeczywiście zrobiłem;) – Finglas
Użyłem go w widoku asp.net MVC, gdzie definiujesz klasę css za pomocą HtmlHelper.
<%= Html.TextBox("Name", null, new { @class = "form-field" }) %>
Dobry przykład ... –
Myślę, że złym pomysłem jest zarezerwowanie słów kluczowych jako nazw zmiennych. IMHO sprawia, że kod jest mniej czytelny. Chociaż istnieją przypadki, w których mogłoby to być przydatne. Na przykład w ASP.NET MVC View można napisać:
<%= Html.TextBox("name", new { @class = "some_css_class" }) %>
unikam go, z wyjątkiem metod rozszerzenie, gdzie myślę, że to pomaga czytelność:
public static void Foo(this object @this)
{
Console.WriteLine(@this.ToString());
}
czy nie uważasz, że kod rzeczywiście powoduje więcej zamieszania, biorąc pod uwagę, że już definiujesz "to"? Wolałbym użyć konwencji nazewnictwa takiej jak "ten obiekt o", tak jak ludzie definiują "i" jako nazwę zmiennej dla int. for (int i = 0; i> ... – David
Myślę, że nie powoduje to zamieszania Pamiętaj, że gdy definiujesz metodę rozszerzenia, jeden z parametrów służy jako odpowiednik "tego" w zwykłej metodzie Wydaje mi się, że wywoływanie tego @ podkreśla ten fakt, szczególnie gdy spogląda się na kod: –
Jeszcze lepiej byłoby wymyślić nazwę parametru, która faktycznie oznacza coś. :) – Guffa
Można bezpiecznie unikać wszystkiego, co tworzy zamieszanie. :-)
Jedyne miejsce, w którym @ używa ciągów.
Od MSDN: Zaletą @ -quoting jest to, że sekwencje nie są przetwarzane, co sprawia, że łatwo pisać, na przykład, w pełni kwalifikowana nazwa pliku:
@"c:\Docs\Source\a.txt" // rather than "c:\\Docs\\Source\\a.txt"
Jak inni wskazano, że @ -quoting może być bardzo przydatny w przypadku łańcuchów. Oto kilka przykładów:
// Not having to escape backslashes.
String a = @"C:\Windows\System32";
// Escaping quotes.
String b = @"The message is ""{0}"".";
// String with embedded newlines.
String c = @"An error occured.
Please try again later.
";
Używam tego cały czas. Znacznie łatwiejsze niż ucieczkę z postaci. – corymathews
Dzięki Marc! To jest naprawdę pomocne. –
"\\ Czy \\ BARDZO \\ przydatne" @ "nie \ Ty \ myślisz?" –
Jednym przypadkiem użycia dla @ napotkanych w ASP.NET MVC, gdy trzeba przekazać anonimowy typ z właściwością o nazwie słowa kluczowego C# jak 'Html.Action (..., nowy {..., @ class = "Test"}); ' –