In C#, int
y Int32
sind das Gleiche, aber ich habe schon mehrmals gelesen, dass int
ist vorzuziehen gegenüber Int32
ohne Angabe von Gründen. Gibt es einen Grund, und sollte mich das interessieren?
Antworten
Zu viele Anzeigen?Die Bytegröße für Typen ist nicht allzu interessant, wenn man nur mit einer einzigen Sprache zu tun hat (und für Code, bei dem man sich nicht an mathematische Überläufe erinnern muss). Interessant wird es, wenn Sie eine Brücke von einer Sprache zu einer anderen schlagen, von C# zu einem COM-Objekt usw., oder wenn Sie eine Bitverschiebung oder Maskierung vornehmen und sich selbst (und Ihre Mitstreiter bei der Codeüberprüfung) an die Größe der Daten erinnern müssen.
In der Praxis verwende ich in der Regel Int32, nur um mich daran zu erinnern, welche Größe sie haben, weil ich sowohl verwaltetes C++ (z. B. als Brücke zu C#) als auch nicht verwaltetes/natives C++ schreibe.
Lange, wie Sie wahrscheinlich wissen, in C # ist 64-Bit, aber in nativen C ++, es endet als 32-Bit, oder char ist unicode/16-Bit, während in C ++ ist es 8-Bit. Aber woher wissen wir das? Die Antwort ist, weil wir im Handbuch nachgeschlagen haben und es dort so steht.
Mit der Zeit und der Erfahrung wird man anfangen, mehr auf den Typ zu achten, wenn man Codes schreibt, um eine Brücke zwischen C# und anderen Sprachen zu schlagen (einige Leser hier werden denken "warum solltest du?"), aber IMHO glaube ich, dass es eine bessere Praxis ist, weil ich mich nicht daran erinnern kann, was ich letzte Woche codiert habe (oder ich muss in meinem API-Dokument nicht angeben, dass "dieser Parameter eine 32-Bit Ganzzahl ist").
Unter F# (obwohl ich es nie benutzt habe), definieren sie int , int32 y nativeint . Es stellt sich die gleiche Frage: "Welches soll ich verwenden?". Wie andere bereits erwähnt haben, sollte es in den meisten Fällen keine Rolle spielen (sollte transparent sein). Aber ich für meinen Teil würde int32 und uint32 wählen, nur um die Zweideutigkeiten zu beseitigen.
Ich schätze, es hängt einfach davon ab, welche Anwendungen Sie programmieren, wer sie benutzt, welche Programmierpraktiken Sie und Ihr Team anwenden usw., um zu rechtfertigen, wann Sie Int32 verwenden.
Nachtrag: Übrigens, seit ich diese Frage vor einigen Jahren beantwortet habe, habe ich angefangen, sowohl F# als auch Rust zu benutzen. In F# dreht sich alles um Typ-Inferenzen und Bridging/InterOp'ing zwischen C# und F#, die nativen Typen stimmen überein, also keine Sorge; ich musste selten explizit Typen in F# definieren (es ist fast eine Sünde, wenn Sie keine Typ-Inferenzen verwenden). In Rust wurden solche Zweideutigkeiten vollständig entfernt und man müsste i32
gegen u32
Alles in allem trägt die Verringerung von Mehrdeutigkeiten zur Reduzierung von Fehlern bei.
Ich verwende immer die Aliasing-Typen (int, string usw.), wenn ich eine Variable definiere, und verwende den echten Namen, wenn ich auf eine statische Methode zugreife:
int x, y;
...
String.Format ("{0}x{1}", x, y);
Es scheint einfach hässlich, etwas wie int.TryParse() zu sehen. Es gibt keinen anderen Grund, warum ich das tue, außer dem Stil.
Nach meiner Erfahrung ist das eine Sache der Konvention. Ich bin mir keines technischen Grundes bewusst, int über Int32 zu verwenden, aber es ist:
- Schneller zu tippen.
- Dem typischen C#-Entwickler ist das eher vertraut.
- Eine andere Farbe in der Standard-Syntaxhervorhebung von Visual Studio.
Das letzte gefällt mir besonders gut :)