En lisant un livre sur C #, j'ai rencontré du code qui utilise le @ sur "surcharger" ou utilisez un mot clé C # comme identifiant. Je suppose que ce n'est pas une bonne pratique, car cela conduit à une ambiguïté. Ai-je raison de penser cela, ou y a-t-il des temps où cela devrait être utilisé?
8 Réponses :
En effet, il vaut presque toujours la peine d'éviter cela. L'heure principale Valide Il pourrait être utile de traiter une bibliothèque externe (d'une autre langue) qui a une classe / etc. qui se trouve être un mot clé C #, mais je vais admettre que j'ai < Strong> Jamais avait ce problème en réalité. Il aide que c # vous permet de renommer les noms d'argument de méthode lors de la mise en place d'interfaces, de manière à éviter un ensemble commun de cas.
une autre utilisation (sans doute paresseux) est en génération de code; Si vous préfixez toujours les champs / variables / etc. avec @thename, vous n'avez pas à vous soucier des cas particuliers. Personnellement, je me crois simplement sur une liste de mots-clés C # / mots clés contextuels et ajoutez quelque chose comme le soulignement.
L'autre utilisation du symbole @ (littérales de chaîne de verbatim) est @ "beaucoup plus utile".
Merci Marc! C'est vraiment utile.
"\\ est \\ très utile" @ "ne pas \ You \ pense?"
Un cas d'utilisation pour @ j'ai rencontré est dans ASP.NET MVC lorsque vous devez passer un type anonyme avec une propriété avec nom d'un mot clé C # comme html.action (..., nouveau {..., @class = "test"});
@Mehrdad: Vérifiez la réponse de David Liddle.
@Fredrick: Wow! Je n'ai pas vu ça. Comme c'est semblable!
Je n'ai utilisé que je n'ai utilisé que dans les cordes seulement, comme:
Je pense que c'est plus utilisable lorsque la chaîne contient: de sorte que vous n'avez pas besoin de vous échapper.
jamais connu à ce sujet, mais de ce que vous dites, je l'éviterais.
La seule fois que j'utilise @ en C # est pour les chaînes pré-formatées.
Je pense que tu voulais dire backslashes
Je l'ai utilisé dans les vues ASP.NET MVC où vous définissez une classe CSS à l'aide d'un HTMLhelper.
<%= Html.TextBox("Name", null, new { @class = "form-field" }) %>
Je pense que c'est une mauvaise idée d'avoir des mots-clés réservés comme noms variables. IMHO, cela rend le code moins lisible. Bien qu'il y ait des cas où cela pourrait être utile. Par exemple dans une vue ASP.NET MVC, vous pouvez écrire:
<%= Html.TextBox("name", new { @class = "some_css_class" }) %>
Je l'évite, sauf avec des méthodes de vulgarisation, où je pense que cela facilite la lisibilité:
public static void Foo(this object @this)
{
Console.WriteLine(@this.ToString());
}
Ne pensez-vous pas que le code provoque réellement plus de confusion que vous définissez déjà «cela»? Je préférerais simplement utiliser une convention de dénomination comme «cet objet O», comme les personnes définissent «I» comme nom de variable pour INTS. Pour (int i = 0; i> ...
Je ne pense pas que cela provoque une confusion. N'oubliez pas que lorsque vous définissez une méthode d'extension, l'un des paramètres sert d'équivalent de «ceci» dans une méthode ordinaire. Je pense que l'appeler @This souligne ce fait, en particulier lors de l'envoi d'un coup d'œil au code.
Encore mieux serait de proposer un nom de paramètre qui signifie réellement quelque chose. :)
Étant donné qu'il s'agit d'une caractéristique plutôt obscure de C #, je pense que cela créera une confusion. Transférer que le paramètre équivaut à "ceci" dans une méthode normale pourrait mieux être servi en écrivant "_this", qui est universellement compris comme un nom simple, tandis que "@" est un métacaracter et mènera à la tête-rayures, à googler et temps perdu.
Vous pouvez éviter tout ce qui crée une confusion. : -)
Le seul endroit que j'utilise @ est avec des chaînes.
de MSDN: L'avantage de @ -quoting est que les séquences d'échappement ne sont pas traitées, ce qui facilite l'écriture, par exemple, un nom de fichier entièrement qualifié:
@ "C: \ DOCS \ SOURCE \ A.TXT" // plutôt que "C: \\ DOCS \\ SOURCE \\ A.TXT"
Comme d'autres ont souligné @ -Quoting peuvent être très utiles avec des chaînes. Voici quelques exemples:
// 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.
";
J'ai tendance à utiliser cela tout le temps. Beaucoup plus facile puis échappant aux personnages.