The problem
Currently the only recommended naming convention for constants is SCREAMING_SNAKE_CASE. This leads to weird APIs, for example:
contract Four {
uint8 public constant FOUR_CONSTANT = 2 + 2;
uint8 public immutable fourImmutable = 2 + 2;
function fourFunction() public pure returns (uint8) {
return 2 + 2;
}
}
For the consumers of the API, it’s all the same, they see 3 pure functions returning uint8
s, but while fourImmutable()
and fourFunction()
are consistent, FOUR_CONSTANT()
is completely different, even though it behaves exactly as the rest.
For the devs writing contracts deriving from Four
, fourImmutable
and FOUR_CONSTANT
are in most contexts equivalent, the only exception are assigning to other constants and static array sizes.
For the devs of Four
, a cosmetic change of fourImmutable
or fourFunction
into a constant is an API-breaking change even though it can’t affect any consumers. A change of FOUR_CONSTANT
into an immutable or a function won’t affect the API consumers either, it will only affect the constant evaluation in the deriving contracts.
Because the naming convention is defined in the Solidity language’s own documentation, it’s considered the (soft) law. All the code linters and analyzers, and also all the devs require using the SCREAMING_SNAKE_CASE for constants, to do otherwise one needs to overcome both the tools and the people.
The solution proposal
I propose to allow both SCREAMING_SNAKE_CASE and mixedCase names in the constants style guide, but recommend mixedCase. It won’t make the existing code and interfaces break the style, after all they can’t be changed anymore. Over time the tools will start accepting mixedCase, and the devs will learn to use them. The future APIs will stick to mixedCase everywhere and won’t expose their inner implementation details via the naming convention anymore.
WDYT?
This post is based on a GitHub issue.