C # und VB.NET enthält eingebaute Typen, die den CLR-Typen zugeordnet sind. Beispiele sind: int (C #) und Integer (VB) werden zu System.Int32, long (C #) und Long (VB) zu System.Int64 zugeordnet. Welche Best Practices sollten verwendet werden, um zu entscheiden, wann integrierte Typen verwendet oder nicht verwendet werden sollen (indem stattdessen die System. * Structs / classes verwendet werden)?
Ich verwende fast immer die eingebauten Aliase wie int / short / long. Sie sind einfacher zu lesen und erfordern nicht das Importieren von System oder das Eingeben von System.Int32 überall usw.
Die Sprache definiert sie klar und gibt ihnen eine spezifische Bedeutung, so dass ich keinen Schaden sehe. Dies ist jedoch zu 100% eine persönliche Entscheidung.
Das heißt - der einzige Ort, an dem ich Int32, Int16 usw. explizit verwende, ist, wenn ich mit binärer Speicherung oder Übertragung arbeite, insbesondere mit einem benutzerdefinierten Binärformat. In diesem Fall macht die explizite Bitgröße jedes Mitglieds, das in die Datei ein- und ausgeht, den Code lesbarer und verständlicher, IMO.
Die Sprachtypen (z. B. string, int, char) sind einfach Aliase für die CLR-Typen (System.String, System.Int32, System.Char).
Sie sind austauschbar, es besteht keine Notwendigkeit, eines vor dem anderen zu bevorzugen.
BEARBEITEN
Das Plakat bat um etwas Hilfe bei der Wahl zwischen den beiden, sehr gut.
Persönlich tendiere ich , die C # -Sprachentypen (int, string, char usw.) zu wählen, weil sie weniger Eingabe erfordern - ich nehme an, ich bin einfach faul:)
Das einzige Mal, dass ich " System.XYZ" " gegenüber einem eingebauten Schlüsselwort explizit verwende, ist, wenn ich einen Integer-Typ mit sehr spezifischer Größe brauche, und ich möchte, dass jeder, der meinen Code liest (z Ich könnte Int32 anstelle von int verwenden, wenn es sich bei der fraglichen Ganzzahl tatsächlich um 4 zusammen gepackte 8-Bit-Felder handelt.)
Ich verwende immer die System.* -Typen, weil sie zwischen anderen Klassen konsistenter aussehen - Großbuchstabe und die gleiche Syntax-Hervorhebung. Aber das ist nur eine persönliche Vorliebe und nur ein ästhetisches Problem.
Anstatt zu verwenden oder nicht die Sprachtypen im Vergleich zu expliziten BCL-Klassennamen zu verwenden, ist es wichtiger zu wissen, ob der Typ, den Sie verwenden möchten, CLS-kompatibel ist.
Insbesondere sind die vorzeichenlosen Integer-Typen nicht CLS-kompatibel, da keine Sprache unterstützt wird, die unsigned integer math. unterstützt.
Abgesehen von dieser Falte ... würde ich empfehlen, welches Idiom mehr mit den Praktiken Ihres Organisationscodes übereinstimmt. Wenn Sie Ihre Typreferenzen vollständig benennen, würde ich dieses Muster mit dem Namespace System. * Fortführen ... (Ich würde jedoch auch empfehlen, diese Vorgehensweise zu verwenden, da die Leselast ohne zusätzliche Klarheit zunimmt).