Laden...

Sollte man Keywords als Identifier verwenden?

Erstellt von Runshak vor 8 Jahren Letzter Beitrag vor 8 Jahren 1.772 Views
R
Runshak Themenstarter:in
71 Beiträge seit 2014
vor 8 Jahren
Sollte man Keywords als Identifier verwenden?

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?

16.807 Beiträge seit 2008
vor 8 Jahren

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.

2.921 Beiträge seit 2005
vor 8 Jahren

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.

2.207 Beiträge seit 2011
vor 8 Jahren

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

A
29 Beiträge seit 2012
vor 8 Jahren

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.

742 Beiträge seit 2005
vor 8 Jahren

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.

656 Beiträge seit 2008
vor 8 Jahren

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.

3.170 Beiträge seit 2006
vor 8 Jahren

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

16.807 Beiträge seit 2008
vor 8 Jahren

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 😃

656 Beiträge seit 2008
vor 8 Jahren

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.