В C # int
и Int32
то же самое, но я прочитал несколько раз, что int
предпочтительнее, Int32
без объяснения причин. Есть ли причина, и я должен заботиться?
c#
variable-types
Грэм
источник
источник
System.Int32
)When something can be read without effort, great effort has gone into its writing.
Easy writing is hard reading
Ответы:
ECMA-334 : 2006 C # Language Specification (p18):
источник
Два действительно являются синонимами;
int
будет немного более знакомым,Int32
сделает 32-битность более понятной для тех, кто читает ваш код. Я был бы склонен использовать,int
где мне просто нужно «целое число»,Int32
где важен размер (криптографический код, структуры), чтобы будущие сопровождающие знали, что безопасно увеличивать,int
если это уместно, но следует позаботиться об измененииInt32
s таким же образом.Результирующий код будет идентичен: разница только в удобочитаемости или внешнем виде кода.
источник
Они оба объявляют 32-битные целые числа, и, как утверждали другие авторы, какой из них вы используете, это в основном вопрос синтаксического стиля. Однако они не всегда ведут себя одинаково. Например, компилятор C # не допустит этого:
но это позволит:
Пойди разберись.
источник
enum
на использованиеint
не являетсяderive
, но указываетunderlying type
; см. msdn.microsoft.com/en-us/library/sbbt4032.aspx#code-snippet-2Я всегда использую системные типы - например,
Int32
вместоint
. Я применил эту практику после прочтения Прикладного программирования на .NET Framework - автор Джеффри Рихтер хорошо обосновывает использование полных имен типов. Вот две вещи, которые застряли со мной:Имена типов могут различаться в зависимости от языка .NET. Например, в C #
long
сопоставляется с System.Int64, а в C ++ с управляемыми расширениямиlong
сопоставляется с Int32. Поскольку языки могут смешиваться и сочетаться при использовании .NET, вы можете быть уверены, что использование явного имени класса всегда будет более понятным, независимо от предпочтительного языка читателя.Многие методы каркаса имеют имена типов как часть своих имен методов:
источник
List<Tuple<Int32, Boolean>> test = new
, Visual Studio теперь будет вставлятьList<Tuple<int, bool>>()
. Знаете ли вы, как изменить эти автозаполнения?var
как можно больше, чтобы уменьшить объемность кода. В тех случайных местах, где автозаполнение приходит и плюет на пол, я настраиваюсь вручную - это буквально секунда или две моего времени.int является ключевым словом C # и является однозначным.
Большую часть времени это не имеет значения, кроме двух вещей, которые идут против Int32:
источник
Как уже говорилось,
int
=Int32
. Чтобы быть в безопасности, всегда используйтеint.MinValue
/int.MaxValue
при реализации всего, что заботится о границах типов данных. Предположим, что .NET решил,int
что теперьInt64
ваш код будет меньше зависеть от границ.источник
int
64-битную, это было бы таким серьезным изменением, что я не верю, что это возможно (или, конечно, разумно) защищать от подобных случайностей.Размер байта для типов не слишком интересен, когда вам приходится иметь дело только с одним языком (и для кода, который вам не нужно напоминать себе о математических переполнениях). Интересной становится часть, когда вы соединяете один язык с другим, C # с COM-объектом и т. Д., Или когда вы выполняете какое-то переключение битов или маскируете, и вам нужно напомнить себе (и вашим коллегам по пересмотру кода) размера данных.
На практике я обычно использую Int32 только для того, чтобы напомнить себе, какого они размера, потому что я пишу управляемый C ++ (например, для соединения с C #), а также неуправляемый / нативный C ++.
Как вы, наверное, знаете, в C # он 64-битный, но в нативном C ++ он заканчивается как 32-битный, или char является unicode / 16-битным, в то время как в C ++ он 8-битный. Но откуда мы это знаем? Ответ таков, потому что мы посмотрели его в руководстве и сказали, что так.
Со временем и опытом вы начнете быть более добросовестным, когда будете писать коды для связи между C # и другими языками (некоторые читатели здесь думают: «Зачем вы?»), Но я думаю, что это лучшая практика, потому что Я не могу вспомнить, что я кодировал на прошлой неделе (или мне не нужно указывать в своем документе API, что «этот параметр является 32-разрядным целым числом»).
В F # (хотя я никогда не использовал его) они определяют int , int32 и nativeint . Тот же самый вопрос должен подняться: «Какой из них я использую?». Как уже упоминали другие, в большинстве случаев это не должно иметь значения (должно быть прозрачным). Но я бы, например, выбрал int32 и uint32, чтобы убрать неясности.
Я полагаю, что это будет зависеть от того, какие приложения вы кодируете, кто его использует, какие практики кодирования вы и ваша команда используете, и т. Д., Чтобы обосновать, когда использовать Int32.
источник
Там нет никакой разницы между
int
иInt32
, но , какint
это ключевое слово языка многие люди предпочитают его стилистически (так же , как иstring
противString
).источник
По моему опыту это было условностью. Я не знаю каких-либо технических причин использовать int поверх Int32, но это:
Я особенно люблю этот последний. :)
источник
Я всегда использую псевдонимы типа (int, string и т. Д.) При определении переменной и реальное имя при доступе к статическому методу:
Просто кажется уродливым видеть что-то вроде int.TryParse (). Нет другой причины, по которой я делаю это, кроме стиля.
источник
Я знаю, что лучше всего использовать int, а весь код MSDN использует int. Однако нет никаких причин, кроме стандартизации и последовательности, насколько я знаю.
источник
Хотя они (в основном) идентичны (см. Ниже разницу [одна ошибка]), вам определенно следует позаботиться об этом и использовать Int32.
Имя для 16-разрядного целого числа - Int16. Для 64-разрядного целого числа это Int64, а для 32-разрядного целого числа интуитивно понятный выбор: int или Int32?
Вопрос о размере переменной типа Int16, Int32 или Int64 является самостоятельным, но вопрос о размере переменной типа int является совершенно правильным вопросом, и вопросы, какими бы тривиальными они ни были, отвлекают, приводят путанице, тратить время, мешать обсуждению и т. д. (факт, что этот вопрос существует, подтверждает это).
Использование Int32 способствует тому, что разработчик осознает свой выбор типа. Насколько большой снова Int? Ах да, 32. Вероятность того, что размер шрифта будет фактически учтен, больше, когда размер включен в имя. Использование Int32 также способствует знанию других вариантов. Когда люди не вынуждены по крайней мере признавать, что есть альтернативы, для int становится слишком легко стать «целочисленным типом».
Класс в рамках, предназначенный для взаимодействия с 32-разрядными целыми числами, называется Int32. Еще раз, что является: более интуитивным, менее запутанным, не имеет (ненужного) перевода (не перевод в системе, а в сознании разработчика) и т. Д.
int lMax = Int32.MaxValue
ИлиInt32 lMax = Int32.MaxValue
?int не является ключевым словом во всех языках .NET.
Хотя есть аргументы, почему он вряд ли когда-либо изменится, int не всегда может быть Int32.
Недостатками являются два дополнительных символа для ввода и [ошибка].
Это не скомпилируется
Но это будет:
источник
Тебя это не должно волновать. Вы должны использовать
int
большую часть времени. Это поможет в будущем перенести вашу программу на более широкую архитектуру (в настоящее времяint
это псевдоним,System.Int32
но это может измениться). Только когда битовая ширина переменной имеет значение (например: для управления макетом в памяти astruct
) вы должны использоватьint32
и другие (со связанной "using System;
").источник
int является ярлыком языка C # для System.Int32
Хотя это действительно означает, что Microsoft может изменить это отображение, в посте обсуждений FogCreek говорится [источник]
«Что касается 64-битной проблемы - Microsoft действительно работает над 64-битной версией .NET Framework, но я уверен, что int НЕ будет отображаться на 64-битную в этой системе.
Причины:
1. Стандарт C # ECMA, в частности, гласит, что int 32-битный, а long 64-битный.
2. Microsoft ввела дополнительные свойства и методы в Framework версии 1.1, которые возвращают длинные значения вместо значений int, такие как Array.GetLongLength в дополнение к Array.GetLength.
Поэтому я думаю, что можно с уверенностью сказать, что все встроенные типы C # сохранят свое текущее отображение ».
источник
int такой же, как System.Int32, и при компиляции он превращается в то же самое в CIL .
Мы используем int по соглашению в C #, так как C # хочет выглядеть как C и C ++ (и Java), и это то, что мы используем там ...
Кстати, я в конечном итоге использую System.Int32 при объявлении импорта различных функций Windows API. Я не уверен, является ли это определенным соглашением или нет, но это напоминает мне, что я иду на внешнюю DLL ...
источник
Когда-то тип данных int был привязан к размеру регистра машины, на которую нацелил компилятор. Так, например, компилятор для 16-битной системы будет использовать 16-битное целое число.
Тем не менее, мы, к счастью, больше не видим 16-битного большого количества, и когда 64-битное начало становиться популярным, люди были более заинтересованы в том, чтобы сделать его совместимым со старым программным обеспечением, а 32-битное было так долго, что для большинства компиляторов int просто предполагается, что это 32 бита.
источник
Я бы порекомендовал использовать StyleCop от Microsoft .
Это похоже на FxCop , но для вопросов, связанных со стилем. Конфигурация по умолчанию соответствует внутренним руководствам по стилю Microsoft, но ее можно настроить для вашего проекта.
Это может занять некоторое время, чтобы привыкнуть, но это определенно делает ваш код приятнее.
Вы можете включить его в процесс сборки, чтобы автоматически проверять наличие нарушений.
источник
int
иInt32
то же самое.int
это псевдоним дляInt32
.источник
using int = System.Int32;
директива для всех ваших файлов исходного кода.Вы не должны заботиться. Если размер имеет значение, я бы использовал byte, short, int, затем long. Единственная причина, по которой вы используете int больше, чем int32, это если вам нужно число больше 2147483647 или меньше -2147483648.
Помимо этого мне было бы все равно, есть много других вопросов, которые могут быть обеспокоены.
источник
На практике это не имеет значения, и со временем вы примете собственное соглашение. Я склонен использовать ключевое слово при назначении типа и версию класса при использовании статических методов и тому подобное:
источник
int
является псевдонимом дляSystem.Int32
, как определено в этой таблице: Таблица встроенных типов (C # Reference)источник
Я использую int в том случае, если Microsoft изменяет реализацию по умолчанию для целого числа на какую-то новую версию с ошибками (назовем это Int32b).
Затем Microsoft может изменить псевдоним int на Int32b, и мне не нужно менять какой-либо мой код, чтобы воспользоваться их новой (и, надеюсь, улучшенной) целочисленной реализацией.
То же самое касается любого из ключевых слов типа.
источник
Вы не должны заботиться о большинстве языков программирования, если вам не нужно писать очень специфические математические функции или код, оптимизированный для одной конкретной архитектуры ... Просто убедитесь, что вам достаточно размера типа (используйте что-то большее, чем Int, если вы знаю, что вам нужно более 32-битных, например)
источник
Это не важно int - это ключевое слово языка, а Int32 - фактический тип системы.
Смотрите также мой ответ здесь на связанный вопрос.
источник
Использование Int или Int32 - это то же самое, что просто упрощение кода для читателя.
Используйте Nullable вариант Int? или Int32? при работе с базами данных на полях, содержащих ноль. Это избавит вас от многих проблем во время выполнения.
источник
Некоторые компиляторы имеют разные размеры для int на разных платформах (не специфично для C #)
Некоторые стандарты кодирования (MISRA C) требуют, чтобы все используемые типы имели заданный размер (т. Е. Int32, а не int).
Также полезно указывать префиксы для переменных разных типов (например, b для 8-битного байта, w для 16-битного слова и l для 32-битного длинного слова => Int32 lMyVariable)
Вы должны быть осторожны, потому что это делает ваш код более переносимым и более удобным в обслуживании.
Переносимость может быть неприменима к C #, если вы всегда собираетесь использовать C # и спецификация C # никогда не изменится в этом отношении.
Поддерживаемое ihmo всегда будет применимо, потому что человек, обслуживающий ваш код, может не знать об этой конкретной спецификации C # и пропустить ошибку, если время от времени int становится больше 2147483647.
В простом цикле for, который подсчитывает, например, месяцы года, вас это не волнует, но когда вы используете переменную в контексте, где она может перетекать, вам следует позаботиться.
Вам также следует позаботиться о том, чтобы выполнять над ним побитовые операции.
источник
It is also good to specify prefixes for different type variables
Венгерская нотация в настоящее время в значительной степени устарела, и большинство стилей кодирования препятствуют ее использованию. Внутренние соглашения компаний-разработчиков также часто запрещают эту записьДля использования
Int32
типа требуется ссылка на пространство именSystem
или полная квалификация (System.Int32
). Я склоняюсь к этомуint
, потому что он не требует импорта пространства имен, поэтому в некоторых случаях снижает вероятность конфликта пространства имен. При компиляции в IL нет никакой разницы между ними.источник
Согласно Immediate Window в Visual Studio 2012 Int32 - это int, Int64 - это длинный. Вот вывод:
источник
Также рассмотрим Int16. Если вам нужно хранить целое число в памяти в вашем приложении и вас беспокоит объем используемой памяти, вы можете использовать Int16, поскольку он использует меньше памяти и имеет меньший минимальный / максимальный диапазон, чем Int32 (то есть, что такое int .)
источник
Некоторое время назад я работал над проектом с Microsoft, когда нас посетил кто-то из команды Microsoft .NET CLR. Этот человек закодировал примеры, и когда он определил свои переменные, он использовал «Int32» против «int» и «String» против «string».
Я вспомнил, как видел этот стиль в другом примере кода от Microsoft. Итак, я провел некоторое исследование и обнаружил, что все говорят, что нет разницы между «Int32» и «int», за исключением раскраски синтаксиса. На самом деле, я нашел много материала, предлагающего вам использовать «Int32», чтобы сделать ваш код более читабельным. Итак, я принял стиль.
На днях я нашел разницу! Компилятор не позволяет вводить enum с помощью «Int32», но делает это, когда вы используете «int». Не спрашивайте меня почему, потому что я еще не знаю.
Пример:
Это работает.
Взято из: Int32 нотации против int
источник