Suggest establishing a code convention guideline for the project

[eomti-wm]

It looks like we don’t have a clearly defined code convention for this project yet.
To keep the codebase consistent and improve readability, I suggest creating a shared guideline (e.g., CODESTYLE.md) that outlines our coding and naming standards.

This would help ensure that everyone follows the same style and make code reviews smoother and more efficient.

Possible areas to include:

• Naming conventions (variables, functions, files, etc.)
• Code formatting (indentation, line length, import order)
• Comment and documentation style
• Commit message format

Additional Context / Notes

• Feedback or suggestions for other areas to include are welcome.

[eomti-wm]

Example (for Solidity)

• Stack variables (input, output, local): use a single _ prefix → _amount, _from, _to
• private and internal state variables: use a double __ prefix → __owner, __balances
• constant variables: all uppercase without prefix (regardless of visibility) → DOMAIN_SEPARATOR
• private and internal functions: use a single _ prefix → _executeTransfer(), _validateSignature()

Inherited Libraries (e.g., OpenZeppelin)

• Keep original names when inheriting from external libraries.
  Do not rename parent contract variables or functions to maintain override compatibility.
• Apply these naming rules only to project-owned contracts.

Handling Naming Conflicts

When a state variable from a parent contract conflicts with one of our stack variables,
use an _ suffix for the stack variable to avoid shadowing:

function _updateBalance(address _account, uint256 _balance_) internal {
    _balances[_account] = _balance_;
}