3.30 Variables

Variable Names

There's a security best practice related to variable names. This ties to the programming style guidelines that we discussed in the Solidity module.

The names of variables should be as distinct and unique from each other as possible because if they are very similar (if they differ by only a few characters or one character), then it could be confusing both to the developer as well as to the security reviewer.

From a developer's perspective, it could lead to replaced usages where the developer uses a different variable than what was intended. As you can imagine, this can have disastrous effects to the functioning of the smart contract.

So variable naming affects readability it affects maintainability and auditability of the code. The best practice is to use very distinct names for the variables meaningful names for the variables, so that errors are avoided.

Uninitialized Variables

Another security pitfall related to variables is the use of uninitialized state or local variables. Remember that in Solidity the default values of uninitialized variables such as address, bool or uint is 0, string is "" and so on.

This results in address variables ending up as the zero address and boolean variables taking the value of false because 0 is effectively false (we have talked about the risks from 0 addresses and bools being false by default will result in the conditionals taking a different branch than what was intended).

The best practice is to make sure that state and local variables are initialized with reasonable values, so that errors are avoided from having the default values being used.

Constants

There is a best practice related to the use of the constant specifier for state variables in Solidity.

State variables whose values do not need to change for the duration of the lifetime of the contract can be declared as constant. This saves Gas because the compiler replaces all the occurrences of such state variables with the constant value. This effectively means that reading such state variables no longer requires the expensive SLOAD instructions.

So the best practice is to identify such state variables whose values do not need to change over the lifetime of the contract and declare them as constant. This also has an additional side effect on improving security because such state variables can no longer be accidentally changed within the different functions of the contract.

Unused State/Local Variables

Another aspect that needs to be paid attention in the use of variables inside contracts is that these could be state variables or local variables. The specific aspect is that if these variables are declared but are never used within the contract.

It could be indicative of missing logic that is expected to be there (that uses these variables in certain ways). It may be missing because the developer forgot to add it or it could simply be indicative of some optimization opportunity where such variables can actually be removed and reduce the size of the byte curve, and therefore reduce the amount of Gas that is used either during deployment or during runtime.

The best practice here is to pay attention to all the variables that are declared (in functions, in the contract, state variables...), see if they are used and, if they are never used, then determine if they need to be removed for optimization, or if there is any logic that is missing that needs to be added that uses those variables.