Open CodeSandwich opened 1 year ago
Hi, @CodeSandwich I'm new to Solidity Project and would like to start contributing with Documentation. Can you please assign it to me.
Hi @ekjotsinghmakhija, sorry, but I can't, I'm not a maintainer :shrug:
For reference, the forum thread: https://forum.soliditylang.org/t/allow-mixedcase-in-the-constants-naming-style/1670.
This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.
It's not stale.
This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.
This issue is still relevant.
This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.
This issue is still relevant
Page
https://docs.soliditylang.org/en/latest/style-guide.html#constants
Abstract
The situation
Currently the only accepted naming convention for constants is SCREAMING_SNAKE_CASE. This leads to weird APIs, for example:
For the consumers of the API, it's all the same, they see 3 pure functions returning
uint8
s, but whilefourImmutable()
andfourFunction()
are consistent,FOUR_CONSTANT()
is completely different, even though it behaves exactly as the rest.For the devs writing contracts deriving from
Four
,fourImmutable
andFOUR_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 offourImmutable
orfourFunction
into a constant is an API-breaking change even though it can't affect any consumers. A change ofFOUR_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
The solution is to allow both SCREAMING_SNAKE_CASE and mixedCase names in constants, 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.
Pull request
None yet, let's discuss it first.