Remove redundant headers

[andreivladbrg]

Headers are useful to improve readability of the code, and to logically group functions between it's visibility and it's type (constant/non-constant).

But, there are places where, IMO, where these headers are a chore (and actually decrease the readability).

E.g. different headers between constants and storage variables, and internal vs private:

v2-core/src/abstracts/SablierV2Base.sol

Lines 24 to 39 in 7819a3b

	/*//////////////////////////////////////////////////////////////////////////
	PUBLIC CONSTANTS
	//////////////////////////////////////////////////////////////////////////*/
	/// @inheritdoc ISablierV2Base
	UD60x18 public constant override MAX_FEE = UD60x18.wrap(0.1e18);
	/*//////////////////////////////////////////////////////////////////////////
	PUBLIC STORAGE
	//////////////////////////////////////////////////////////////////////////*/
	/// @inheritdoc ISablierV2Base
	ISablierV2Comptroller public override comptroller;
	/// @inheritdoc ISablierV2Base
	mapping(IERC20 asset => uint128 revenues) public override protocolRevenues;

My proposal is to use only one header for these variables, and that is:

    /*//////////////////////////////////////////////////////////////////////////
                                 CONTRACT STATE
    //////////////////////////////////////////////////////////////////////////*/

wdyt? @PaulRBerg @smol-ninja

[scorpion9979]

@andreivladbrg When discussing changes that don't impact code performance, I'm of the opinion of optimizing code readability for auditors. I think categorized headers could be further made valuable when supercharged with region folding. Region comments in Solidity are already supported by juanfranblanco's VSCode extension, but I've been trying to have Hardhat support it as well.

[andreivladbrg]

thank you for your answer, and i am sorry for the random tag, it was mistake

[scorpion9979]

@andreivladbrg We're good! No need to apologize :)

[PaulRBerg]

Interesting proposal.

I am not sure, however, if what you mean is get rid of the public<>internal dichotomy for storage variables only? Or do you want that for functions, as well?

[andreivladbrg]

I precisely said "State" to refer to both constants and storage variables which is correct and not confusing in context of EVM.

As we can see here: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf
There are two kinds of accounts, EOAs and contracts.

Contracts accounts' state is both storage and code:

Thus, we should use CONTRACT STATE for both

[smol-ninja]

I must say you made a very interesting point by referring to the definition of CONTRACT STATE in the context of EVM. However, as I was thinking about it, I wondered if we should use terminologies in the context of EVM or solidity language.

For example, in the context of Solidity, state variables are used for both storage variables as well as constants.

1. State variables are variables whose values are permanently stored in contract storage.
2. State variables can be declared as constant or immutable.

I am not saying that we should use STATE VARIABLES instead of CONTRACT STATE but out of curiosity, what do you think about this?

PS: State variables (constants + storage variables) appears to be a subset of contract state (nonce, balance, storage variables, deployed code).

[andreivladbrg]

I wondered if we should use terminologies in the context of EVM or solidity language

Tbh, this sentence doesn't make sense to me. Isn't Solidity the language that targets the EVM😅?

For me, it doesn't matter if it is either CONTRACT STATE or STATE VARIABLES, both work.

My response was just against the idea that we should have two different headers for storage and constants, when we can refer to both, as state.

Basically responding to these.
Shub:

Do you plan to use CONTRACT STATE for all of them? If yes, I think it would be a good idea to not use it for constants because technically they are not contract states. We can have CONSTANTS (to cover internal, private and public) and CONTRACT STATE (to cover private, public and internal).

PRB:

I agree that using CONSTANTS and CONTRACT STATE is better.

[smol-ninja]

I agree with you. And I was wrong to say that constants are not contract states. They indeed are.

[PaulRBerg]

I wondered if we should use terminologies in the context of EVM or solidity language

This sentence does make sense to me.

Isn't Solidity the language that targets the EVM😅?

It does target the EVM, but it can contain a higher-level concept that has nothing to do (directly) with raw EVM bytecode.

---

I suggest making a PR to see what the new headers look like in practice.

We can make a decision on the spot - whether we like it without CONSTANTS, or not.

[PaulRBerg]

Also FYI @andreivladbrg, we don't apply labels to discussions.