Hallo, ich habe endlich eine schöne Videoplaylist auf Youtube gefunden zum lernen von C#. Das ganze sind Videos aus Vorlesungen an einer Uni.
Der Prof. nutzt in einem seiner Videos die Möglichkeit Bezeichner zu wählen, die schon reserviert sind. Bsp. "String" er setzt dafür vor den Bezeichner das "@"... ist das überhaupt sinnvoll? bzw. wird das von "Profis" häufig verwendet?
[edit]
String @string = ...
so heißt jetzt das Ding string und kann verwendet werden...ist das sinnvoll?
Profis verwenden jedenfalls Foren-Threads, mit denen man was anfangen kann
[Hinweis] Wie poste ich richtig? Punkt 3. Ich hab das mal geändert...
Ansonsten:
[FAQ] Was bedeutet das @ (=at) vor String-Literalen? Und: Wissenswertes zu Escape-Sequenzen
--- Edit:
Ach Du sprichst von Keywords.
Nein, das ist nicht sinnvoll und sollte von jeden vermeiden werden.
Es macht (in meinen Augen) nur sinn, wenn man eine Bibliothek hat, deren Parameterbezeichnungen eine Eindeutigkeit herstellen können oder sollen, zB bei Erweiterungsmethoden, dass der Parameter "value" heisst.
public static String GetAny(this String @value)
{
}
PS: verwende daraufhin bitte in Zukunft die Antworten-Variante.
Ich wurde auf Dein Edit nur aufmerksam, da mir jemand per PN geschrieben hat.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Im oberen verwiesenen Thread geht es ja nur darum, wie man das @ für Strings benutzen kann.
Du aber meinst @Runshak ob das sinnvoll ist:
string @string = "";
oder z.B.
string @class = "";
richtig?
Ich weiss zwar, dass das geht, aber kann mich nicht erinnern das in meinen Programmen zu benutzen.
Benutze es also nicht. Keine Ahnung ob andere das benutzen
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.
Ob Profi oder nicht: Sowas sollte man nicht machen.
Kein Mensch weiss, was die Variable mit dem Namen "string" darstellt. Das wäre genauso, als würde man eine Liste "list" nennen. Da kann alles drin sein. Wenn man nicht wirklich triftige Gründe hat sowas zu machen sollte man es lassen.
Gruss
Coffeebean
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
Ausnahmen bestätigen natürlich die Regel, aber wie Abt und Coffeebean schon sagten, sollte man das devinitiv vermeiden.
Variablennamen sind ja Informationsträger (Semantik) und tragen damit erheblich zur Lesbar- und Verständlichkeit des Programmcodes bei. Was also syntaktisch korrekt ist, kann semantisch völlig verkehrt sein. Z.B.: int @string = 1;
- eine Variable mit dem Namen string, der Typ ist aber int
.
Im Zusammenhang mit der Vorlesung des Profs wäre vermutlich die Variablenbezeichnung sampleString sinnvoller (sofern die Logik des Programmcodes nicht einen noch treffenderen Namen hergibt, wie etwa string name = "...";
, wenn man einen Namen speichert).
Jeder Entwickler sollte jegliche Identifier, seien es Variablen-, Klassen- oder Methodennamen immer bedacht und sinnvoll vergeben. Das hilft nicht nur einem selbst, indem man sich klar wird, was genau gemacht werden soll, sondern hilft auch anderen Entwicklern beim Lesen und Verstehen von fremdem Code.
Ich verwende abunzu @event. z.B.
void Handle(UserCreatedEvent @event) {}. Ganz selten außerdem noch @class, wenn ich mit Reflection arbeite. Aber ansonsten fällt mir gerade kein Keyword ein, dass noch neben value sinn macht.
ImageTools for Silverlight: http://imagetools.codeplex.com | http://www.silverdiagram.net | http://www.cleancodedeveloper.de b:::
Aber ansonsten fällt mir gerade kein Keyword ein, dass noch neben value sinn macht.
Eventuell this
bei Extension-Methoden?
public static void DoSomething(this MyClass @this)
{
DoSomethingElseWith(@this);
}
Aber selbst das ist schon ein wenig grenzwertig und könnte je nach Sinn der Methode durch einen brauchbarer benannten Parameternamen ersetzt werden.
Hallo zusammen,
der wichtigste - und genau genommen einzige - Anwendungsfall, bei dem mir das sinnvoll erscheint, ist wenn man Schnittstellen (z.B. zu Komponenten, die in anderen Sprachen erstellt wurden) erfüllen will, und sich dazu an bestimmte Namenskonventionen halten muss.
Dann ist es ein nützliches Feature, dass eine solche Möglichkeit besteht. In allen anderen Fällen würde ich davon aber unbedingt Abstand nehmen!!
Gruß, MarsStein
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca
Eventuell
this
bei Extension-Methoden?public static void DoSomething(this MyClass @this) { DoSomethingElseWith(@this); }
Es macht (in meinen Augen) nur sinn, wenn man eine Bibliothek hat, deren Parameterbezeichnungen eine Eindeutigkeit herstellen können oder sollen, zB bei Erweiterungsmethoden, dass der Parameter "value" heisst.
public static String GetAny(this String @value) { }
Wobei sogar "source" gewöhnlicher ist als @value - und @this hab ich noch nie gesehen.
Das würde ich direkt wieder abgewöhnen 😃
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Das würde ich direkt wieder abgewöhnen 😃
Wo wir wieder beim Thema "lieber sinnvoller benennen" wären. Um ehrlich zu sein hab ich auch nur eine einzige Extension Methode in unseren Projekten gefunden, die @this
benutzt - und nicht mal verwendet wird.
Wenns nicht grade von einem Legacy-System her für irgendwelche Matches benötigt wird, halte ich persönlich eh auch Abstand davon - aber das wurde hier eh schon zu Genüge erwähnt.