Is uint
the same as uint256
in Solidity?
If this is the case, then why do a lot smart contracts make extensive use of uint256
and not just write uint
instead? Is this merely to be explicit?
Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this communityIs uint
the same as uint256
in Solidity?
If this is the case, then why do a lot smart contracts make extensive use of uint256
and not just write uint
instead? Is this merely to be explicit?
Yes, they are exact aliases.
Some developers (including me) prefer to use uint256
because it is consistent with other uint
data types, which also specify their size, and also because making the size of the data explicit reminds the developer and the reader how much data they've got to play with, which may help prevent or detect bugs.
Some other languages have left out the bare uint
version for just these reasons. For example, Bamboo only has uint256
.
I hate to say RTFM, but this one was too trivial. "uint and int are aliases for uint256 and int256, respectively." --https://solidity.readthedocs.io/en/v0.4.21/types.html#value-types
uint256
instead of uint
in contracts? I see this a lot and it seems unnecessary
– Eliezer Steinbock
Mar 19 '18 at 21:44
uint256
either to be explicit with their code in case of any changes to the alias of uint
and it's visually easier to read.
– ReyHaynes
Mar 19 '18 at 22:05
In addition to what @EdmundEdgar said, it's also better to be explicit when constructing method signature ID's.
For example if doing bytes4(keccak('transfer(address, uint)'))
, you'll get a different method sig ID than bytes4(keccak('transfer(address, uint256)'))
and smart contracts will only understand the latter when comparing method sig IDs.
I think it's best to use uint256
. It brings about readability and consistency in your code, and it allows you to adhere to best practices in smart contracts.