W języku C # int
i Int32
są tym samym, ale przeczytałem wiele razy, że int
jest to preferowane Int32
bez podania przyczyny. Czy jest jakiś powód i czy powinienem się tym przejmować?
c#
variable-types
Graham
źródło
źródło
System.Int32
)When something can be read without effort, great effort has gone into its writing.
Easy writing is hard reading
Odpowiedzi:
ECMA-334 : 2006 C # Specyfikacja języka (p18):
źródło
Oba są rzeczywiście synonimami;
int
będzie nieco bardziej znajomy,Int32
sprawi , że 32-bitowość będzie bardziej wyraźna dla osób czytających Twój kod. Byłbym skłonny używaćint
tam, gdzie potrzebuję tylko „liczby całkowitej”,Int32
gdzie rozmiar jest ważny (kod kryptograficzny, struktury), aby przyszli opiekunowie wiedzieli, że bezpieczne jest powiększenie,int
jeśli to właściwe, ale powinni dbać o zmianęInt32
w ten sam sposób.Wynikowy kod będzie identyczny: różnica polega wyłącznie na czytelności lub wyglądzie kodu.
źródło
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:
ale pozwoli to na:
Domyśl.
źródło
enum
do użyciaint
nie jestderive
, ale określenieunderlying type
; patrz msdn.microsoft.com/en-us/library/sbbt4032.aspx#code-snippet-2Zawsze używam typów systemów - np.
Int32
Zamiastint
. 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:Nazwy typów mogą się różnić między językami .NET. Na przykład w języku C #,
long
mapy do System.Int64, podczas gdy w C ++ z zarządzanymi rozszerzeniami,long
mapy 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.Wiele metod frameworkowych ma nazwy typów jako część nazw metod:
źródło
List<Tuple<Int32, Boolean>> test = new
, Visual Studio teraz wstawiList<Tuple<int, bool>>()
. Czy znasz sposób na zmianę tych autouzupełniania?var
jak najwięcej, aby zmniejszyć słowność kodu. W tych sporadycznych miejscach, w których autouzupełnianie przychodzi i pluje na moją podłogę, dostosowuję się ręcznie - to dosłownie sekunda lub dwa mojego czasu.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:
źródło
Jak już wspomniano,
int
=Int32
. Aby być bezpiecznym, pamiętaj, aby zawsze używaćint.MinValue
/int.MaxValue
podczas implementowania czegokolwiek, co dotyczy granic typów danych. Załóżmy, że .NET zdecydował,int
że teraz będzieInt64
, twój kod będzie mniej zależny od granic.źródło
int
64 bity, byłaby to tak przełomowa zmiana, że nie sądzę, aby możliwe było (lub na pewno rozsądne) kodowanie obronne przed takimi ewentualnościami.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.
źródło
Nie ma różnicy między
int
iInt32
, ale ponieważint
jest słowem kluczowym dla języka, wiele osób woli je stylistycznie (podobnie jak w przypadkustring
vsString
).źródło
Z mojego doświadczenia wynika, że była to konwencja. Nie znam żadnego technicznego powodu, aby używać int przez Int32, ale jest to:
Szczególnie podoba mi się ten ostatni. :)
źródło
Zawsze używam typów aliasowanych (int, string itp.) Podczas definiowania zmiennej i używam prawdziwej nazwy podczas uzyskiwania dostępu do metody statycznej:
Po prostu brzydko jest widzieć coś takiego jak int.TryParse (). Nie ma innego powodu, dla którego robię to inaczej niż styl.
źródło
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ą.
źródło
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.MaxValue
LubInt32 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
Ale to:
źródło
Nie powinieneś się tym przejmować. Powinieneś używać przez
int
większość czasu. Pomoże w przyszłości przenieść twój program do szerszej architektury (obecnieint
jest to alias do,System.Int32
ale to może się zmienić). Tylko wtedy, gdy szerokość bitów zmiennej ma znaczenie (na przykład: aby sterować układem w pamięci astruct
), powinieneś użyćint32
i innych (z powiązanym „using System;
”).źródło
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. ”
źródło
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 ...
źródło
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.
źródło
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.
źródło
int
iInt32
jest taki sam.int
jest pseudonimem dlaInt32
.źródło
using int = System.Int32;
dyrektywy dla wszystkich plików kodu źródłowego.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ć.
źródło
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:
źródło
int
jest aliasem dlaSystem.Int32
, zgodnie z definicją w tej tabeli: Tabela typów wbudowanych (C # Reference)źródło
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.
źródło
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)
źródło
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.
źródło
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.
źródło
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.
źródło
It is also good to specify prefixes for different type variables
Notacja węgierska jest obecnie w dużej mierze przestarzała, a większość stylów kodowania zniechęca do jej używania. Wewnętrzne konwencje firm produkujących oprogramowanie również często zabraniają tego zapisuKorzystanie z tego
Int32
typu wymaga odwołania do przestrzeni nazwSystem
lub pełnego kwalifikowania się (System.Int32
). Skłaniam się ku temuint
, 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.źródło
Według Natychmiastowego okna w Visual Studio 2012 Int32 to int, Int64 jest długi. Oto wynik:
źródło
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 .)
źródło
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:
To działa.
Zaczerpnięte z: Notacja Int32 vs. int
źródło