Czy powinienem użyć int lub Int32

W języku C # inti Int32są tym samym, ale przeczytałem wiele razy, że intjest to preferowane Int32bez podania przyczyny. Czy jest jakiś powód i czy powinienem się tym przejmować?

ECMA-334 : 2006 C # Specyfikacja języka (p18):

Każdy z predefiniowanych typów jest skrótem dla typu dostarczanego przez system. Na przykład słowo kluczowe intodnosi się do struktury System.Int32. Ze względu na styl użycie słowa kluczowego jest preferowane zamiast użycia pełnej nazwy typu systemu.

Oba są rzeczywiście synonimami; intbędzie nieco bardziej znajomy, Int32sprawi , że 32-bitowość będzie bardziej wyraźna dla osób czytających Twój kod. Byłbym skłonny używać inttam, gdzie potrzebuję tylko „liczby całkowitej”, Int32gdzie rozmiar jest ważny (kod kryptograficzny, struktury), aby przyszli opiekunowie wiedzieli, że bezpieczne jest powiększenie, intjeśli to właściwe, ale powinni dbać o zmianę Int32w ten sam sposób.

Wynikowy kod będzie identyczny: różnica polega wyłącznie na czytelności lub wyglądzie kodu.

Obie deklarują 32-bitowe liczby całkowite i, jak stwierdzili inni plakaty, który z nich jest używany, zależy głównie od stylu syntaktycznego. Jednak nie zawsze zachowują się w ten sam sposób. Na przykład kompilator C # nie pozwoli na to:

public enum MyEnum : Int32
{
    member1 = 0
}

ale pozwoli to na:

public enum MyEnum : int
{
    member1 = 0
}

Domyśl.

Zawsze używam typów systemów - np. Int32Zamiast int. Przyjąłem tę praktykę po przeczytaniu Applied .NET Framework Programming - autor Jeffrey Richter uzasadnia użycie pełnych nazw typów. Oto dwa punkty, które mi utknęły:

1. Nazwy typów mogą się różnić między językami .NET. Na przykład w języku C #, longmapy do System.Int64, podczas gdy w C ++ z zarządzanymi rozszerzeniami, longmapy do Int32. Ponieważ języki mogą być mieszane i dopasowywane podczas korzystania z .NET, możesz być pewien, że użycie jawnej nazwy klasy będzie zawsze wyraźniejsze, bez względu na preferowany język czytelnika.

2. Wiele metod frameworkowych ma nazwy typów jako część nazw metod:

   BinaryReader br = new BinaryReader( /* ... */ );
   float val = br.ReadSingle();     // OK, but it looks a little odd...
   Single val = br.ReadSingle();    // OK, and is easier to read

int jest słowem kluczowym C # i jest jednoznaczny.

W większości przypadków nie ma to znaczenia, ale dwie rzeczy, które są sprzeczne z Int32:

• Musisz mieć „korzystanie z systemu”; komunikat. użycie „int” nie wymaga użycia instrukcji.
• Możliwe jest zdefiniowanie własnej klasy o nazwie Int32 (co byłoby głupie i mylące). int zawsze oznacza int.

Jak już wspomniano, int= Int32. Aby być bezpiecznym, pamiętaj, aby zawsze używać int.MinValue/ int.MaxValuepodczas implementowania czegokolwiek, co dotyczy granic typów danych. Załóżmy, że .NET zdecydował, intże teraz będzie Int64, twój kod będzie mniej zależny od granic.

Rozmiar bajtu dla typów nie jest zbyt interesujący, gdy masz do czynienia tylko z jednym językiem (i dla kodu, którego nie musisz przypominać o przepełnieniu matematyki). Część, która staje się interesująca, to kiedy łączysz jeden język z drugim, C # do obiektu COM itp., Lub robisz trochę przesuwania bitów lub maskowania i musisz sobie przypomnieć (i współpracownikom weryfikującym kod) wielkości danych.

W praktyce zwykle używam Int32 tylko po to, żeby sobie przypomnieć, jaki mają rozmiar, ponieważ piszę zarządzany C ++ (na przykład do mostkowania do C #), a także niezarządzany / natywny C ++.

O ile zapewne wiesz, w C # ma 64 bity, ale w natywnym C ++ kończy się na 32 bity, lub char to Unicode / 16 bitów, podczas gdy w C ++ jest to 8 bitów. Ale skąd to wiemy? Odpowiedź brzmi, ponieważ sprawdziliśmy to w instrukcji i tak powiedział.

Z czasem i doświadczeniami zaczniesz być bardziej sumienny, pisząc kody w celu pomostu między C # i innymi językami (niektórzy czytelnicy myślą tutaj „dlaczego byś?”), Ale IMHO uważam, że jest to lepsza praktyka, ponieważ Nie pamiętam, co napisałem w zeszłym tygodniu (lub nie muszę podawać w dokumencie API, że „ten parametr jest liczbą całkowitą 32-bitową”).

W języku F # (chociaż nigdy go nie użyłem), definiują int , int32 i nativeint . To samo pytanie powinno się pojawić: „z którego korzystam?”. Jak wspomnieli inni, w większości przypadków nie powinno to mieć znaczenia (powinno być przejrzyste). Ale dla jednego wybrałbym int32 i uint32 tylko po to, aby usunąć niejasności.

Wydaje mi się, że będzie to zależeć tylko od tego, jakie aplikacje kodujesz, kto go używa, jakie praktyki kodowania stosujesz ty i twój zespół itp., Aby uzasadnić, kiedy używać Int32.

Nie ma różnicy między inti Int32, ale ponieważ intjest słowem kluczowym dla języka, wiele osób woli je stylistycznie (podobnie jak w przypadku stringvs String).

Z mojego doświadczenia wynika, że ​​była to konwencja. Nie znam żadnego technicznego powodu, aby używać int przez Int32, ale jest to:

1. Szybsze pisanie.
2. Bardziej znany typowemu programistowi C #.
3. Inny kolor w domyślnym podświetlaniu składni studia wizualnego.

Szczególnie podoba mi się ten ostatni. :)

Zawsze używam typów aliasowanych (int, string itp.) Podczas definiowania zmiennej i używam prawdziwej nazwy podczas uzyskiwania dostępu do metody statycznej:

int x, y;
...
String.Format ("{0}x{1}", x, y);

Po prostu brzydko jest widzieć coś takiego jak int.TryParse (). Nie ma innego powodu, dla którego robię to inaczej niż styl.

Wiem, że najlepszą praktyką jest używanie int, a cały kod MSDN używa int. O ile mi wiadomo, nie ma powodu poza standaryzacją i spójnością.

Chociaż są (przeważnie) identyczne (zobacz poniżej różnicę [błąd]), zdecydowanie powinieneś się tym przejmować i powinieneś używać Int32.

• Nazwa 16-bitowej liczby całkowitej to Int16. Dla 64-bitowej liczby całkowitej jest to Int64, a dla 32-bitowej liczby całkowitej intuicyjny wybór to: int lub Int32?

• Pytanie o wielkość zmiennej typu Int16, Int32 lub Int64 jest samo-referencyjne, ale pytanie o wielkość zmiennej typu int jest całkowicie poprawnym pytaniem i pytania, bez względu na to, jak trywialne, rozpraszają, prowadzą do zamieszania, marnowania czasu, utrudniania dyskusji itp. (fakt, że to pytanie istnieje, dowodzi tego).

• Korzystanie z Int32 promuje świadomość, że programista jest świadomy wyboru rodzaju. Jak duży jest znowu int? O tak, 32. Prawdopodobieństwo uwzględnienia rozmiaru typu jest większe, gdy rozmiar jest zawarty w nazwie. Korzystanie z Int32 promuje również wiedzę o innych opcjach. Kiedy ludzie nie są zmuszeni przynajmniej rozpoznać, że istnieją alternatywy, int staje się zdecydowanie zbyt łatwe, aby stać się „typem całkowitym”.

• Klasa w ramach przeznaczona do interakcji z 32-bitowymi liczbami całkowitymi nosi nazwę Int32. Jeszcze raz, co jest: bardziej intuicyjne, mniej mylące, brakuje (niepotrzebnego) tłumaczenia (nie tłumaczenia w systemie, ale w myślach dewelopera) itp. int lMax = Int32.MaxValueLub Int32 lMax = Int32.MaxValue?

• int nie jest słowem kluczowym we wszystkich językach .NET.

• Chociaż istnieją argumenty, że prawdopodobnie nigdy się nie zmieni, int może nie zawsze być Int32.

Wadami są dwa dodatkowe znaki do wpisania i [błąd].

To się nie skompiluje

public enum MyEnum : Int32
{
    AEnum = 0
}

Ale to:

public enum MyEnum : int
{
    AEnum = 0
}

Nie powinieneś się tym przejmować. Powinieneś używać przez intwiększość czasu. Pomoże w przyszłości przenieść twój program do szerszej architektury (obecnie intjest to alias do, System.Int32ale to może się zmienić). Tylko wtedy, gdy szerokość bitów zmiennej ma znaczenie (na przykład: aby sterować układem w pamięci a struct), powinieneś użyć int32i innych (z powiązanym „ using System;”).

int to skrót języka C # do System.Int32

Chociaż oznacza to, że Microsoft może zmienić to mapowanie, w postie na temat dyskusji FogCreek stwierdzono [źródło]

„W kwestii 64-bitowej - Microsoft rzeczywiście pracuje nad 64-bitową wersją .NET Framework, ale jestem pewien, że int NIE będzie mapowany na 64-bitowy w tym systemie.

Powody:

1. Standard C # ECMA wyraźnie mówi, że int jest 32-bitowy, a długi - 64-bitowy.

2. Microsoft wprowadził dodatkowe właściwości i metody w Framework wersja 1.1, które zwracają długie wartości zamiast wartości int, takie jak Array.GetLongLength oprócz Array.GetLength.

Myślę więc, że można bezpiecznie powiedzieć, że wszystkie wbudowane typy C # zachowają swoje aktualne mapowanie. ”

int jest taki sam jak System.Int32, a po skompilowaniu zmieni się w CIL w to samo .

Używamy int zgodnie z konwencją w C #, ponieważ C # chce wyglądać jak C i C ++ (i Java) i tego właśnie używamy ...

BTW, kończę przy użyciu System.Int32, kiedy deklaruję import różnych funkcji Windows API. Nie jestem pewien, czy jest to zdefiniowana konwencja, czy nie, ale przypomina mi, że idę do zewnętrznej biblioteki DLL ...

Dawno, dawno temu typ danych int był powiązany z wielkością rejestru komputera docelowego przez kompilator. Na przykład kompilator dla 16-bitowego systemu użyłby 16-bitowej liczby całkowitej.

Jednak na szczęście nie widać dużo 16-bitowy więcej, a gdy 64-bitowy zaczęły się popularne ludzie byli bardziej zainteresowani co kompatybilny ze starszym oprogramowaniem i 32-bitowy było wokół tak długo, że dla większości kompilatorów int zakłada się, że ma 32 bity.

Polecam korzystanie z Microsoft StyleCop .

To jest jak FxCop , ale dotyczy problemów związanych ze stylem. Domyślna konfiguracja jest zgodna z wewnętrznymi przewodnikami stylu firmy Microsoft, ale można ją dostosować do projektu.

Przyzwyczajenie się do tego może trochę potrwać, ale zdecydowanie poprawia kod.

Możesz uwzględnić go w procesie kompilacji, aby automatycznie sprawdzać, czy nie występują naruszenia.

inti Int32jest taki sam. intjest pseudonimem dla Int32.

Nie powinieneś się tym przejmować. Jeśli problemem jest rozmiar, użyłbym bajtu, short, int, a następnie long. Jedynym powodem, dla którego użyjesz liczby większej niż int32, jest to, że potrzebujesz liczby wyższej niż 2147483647 lub mniejszej niż -2147483648.

Poza tym nie dbam o to, jest wiele innych rzeczy, którymi należy się martwić.

W praktyce nie ma to znaczenia, a z czasem przyjmiecie własną konwencję. Zazwyczaj używam słowa kluczowego podczas przypisywania typu, a wersji klasowej przy użyciu metod statycznych i takich:

int total = Int32.Parse("1009");

intjest aliasem dla System.Int32, zgodnie z definicją w tej tabeli: Tabela typów wbudowanych (C # Reference)

Korzystam z int w przypadku, gdy Microsoft zmieni domyślną implementację liczby całkowitej na jakąś nową wersję fangled (nazwijmy to Int32b).

Microsoft może następnie zmienić alias int na Int32b i nie muszę zmieniać żadnego mojego kodu, aby skorzystać z ich nowej (i mam nadzieję ulepszonej) implementacji liczb całkowitych.

To samo dotyczy słów kluczowych typu.

Nie powinieneś się przejmować większością języków programowania, chyba że musisz pisać bardzo specyficzne funkcje matematyczne lub kod zoptymalizowany dla jednej konkretnej architektury ... Upewnij się, że rozmiar tego typu jest dla Ciebie wystarczający (użyj czegoś większego niż Int, jeśli wiedz , że na przykład potrzebujesz więcej niż 32-bitów)

To nie ma znaczenia int jest słowem kluczowym języka, a Int32 to jego rzeczywisty typ systemu.

Zobacz także moją odpowiedź tutaj na powiązane pytanie.

Użycie Int lub Int32 są takie same Int jest tylko cukrem, aby uprościć kod dla czytnika.

Skorzystać z wariantu dopuszczającego wartość zerową Int? lub Int32? podczas pracy z bazami danych na polach zawierających wartość null. Pozwoli to uchronić Cię przed wieloma problemami w czasie wykonywania.

Niektóre kompilatory mają różne rozmiary dla int na różnych platformach (nie specyficzne dla C #)

Niektóre standardy kodowania (MISRA C) wymagają, aby wszystkie użyte typy miały określony rozmiar (tj. Int32, a nie int).

Dobrze jest również określić prefiksy dla zmiennych różnych typów (np. B dla 8-bitowego bajtu, w dla 16-bitowego słowa, l dla 32-bitowego słowa => Int32 lMyVariable)

Powinieneś się tym przejmować, ponieważ dzięki temu Twój kod jest bardziej przenośny i łatwiejszy w utrzymaniu.

Portable może nie mieć zastosowania do C #, jeśli zawsze zamierzasz używać C #, a specyfikacja C # nigdy się nie zmieni w tym zakresie.

Utrzymywalne ihmo zawsze będzie miało zastosowanie, ponieważ osoba utrzymująca Twój kod może nie być świadoma tej konkretnej specyfikacji C # i przegapić błąd, gdy okazjonalnie staje się więcej niż 2147483647.

W prostej pętli for, która liczy na przykład miesiące roku, nie będziesz się tym przejmować, ale kiedy używasz zmiennej w kontekście, w którym może ona przepłynąć, powinieneś się tym przejmować.

Powinieneś także dbać o to, czy zamierzasz wykonywać na nim operacje bitowe.

Korzystanie z tego Int32typu wymaga odwołania do przestrzeni nazw Systemlub pełnego kwalifikowania się ( System.Int32). Skłaniam się ku temu int, ponieważ nie wymaga importu przestrzeni nazw, dlatego w niektórych przypadkach zmniejsza ryzyko kolizji przestrzeni nazw. Po skompilowaniu do IL nie ma między nimi żadnej różnicy.

Według Natychmiastowego okna w Visual Studio 2012 Int32 to int, Int64 jest długi. Oto wynik:

sizeof(int)
4
sizeof(Int32)
4
sizeof(Int64)
8
Int32
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648
Int64
long
    base {System.ValueType}: System.ValueType
    MaxValue: 9223372036854775807
    MinValue: -9223372036854775808
int
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648

Weź również pod uwagę Int16. Jeśli potrzebujesz zapisać liczbę całkowitą w pamięci w swojej aplikacji i martwisz się ilością używanej pamięci, możesz skorzystać z Int16, ponieważ zużywa mniej pamięci i ma mniejszy zakres min / max niż Int32 (co jest int .)

Jakiś czas temu pracowałem nad projektem z Microsoftem, kiedy odwiedziliśmy kogoś z zespołu produktu Microsoft .NET CLR. Osoba ta kodowała przykłady, a kiedy zdefiniował swoje zmienne, używał „Int32” vs. „int” i „String” vs. „string”.

Pamiętałem, że widziałem ten styl w innym przykładowym kodzie Microsoft. Przeprowadziłem więc badania i stwierdziłem, że wszyscy twierdzą, że nie ma różnicy między „Int32” a „int”, z wyjątkiem kolorowania składni. W rzeczywistości znalazłem wiele materiałów sugerujących użycie „Int32”, aby twój kod był bardziej czytelny. Więc przyjąłem styl.

Któregoś dnia znalazłem różnicę! Kompilator nie pozwala na wpisywanie wyliczenia za pomocą „Int32”, ale robi to, gdy używasz „int”. Nie pytaj mnie dlaczego, bo jeszcze nie wiem.

Przykład:

public  enum MyEnum : Int32
{
    AEnum = 0
}

To działa.

public enum MyEnum : int
{
    AEnum = 0
}

Zaczerpnięte z: Notacja Int32 vs. int