Rethink current naming convention in contracts

[bidzyyys]

What is the feature you would like to see?

Right now we use in some cases Solidity like naming convention (_do_sth()). It is not recommended attitude in Rust and causes cargo clippy issues (right now disabled). We should rethink this topic and make sure our library is consistent in terms of naming.

Related #491
Related #499

TODO: Remove _ prefix from state variables (for functions see #386 (comment))

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines

[bidzyyys]

The same applies for struct attributes, like _pub _owner: StorageAddress,

[0xNeshi]

Do we include test name standardization in this issue as well?

• function_name_description for standard tests.
• function_name_revert_when_condition for tests expecting a revert

[bidzyyys]

Do we include test name standardization in this issue as well?

• function_name_description for standard tests.
• function_name_revert_when_condition for tests expecting a revert

@0xNeshi not in this issue, for test name standardisation I suggest having another one. Easier to solve & merge.

[0xNeshi]

Makes sense, created a separate issue #491

[0xNeshi]

@bidzyyys @qalisander

In Solidity, internal functions use the _fn_name prefix pattern, making their visibility immediately clear. In our Rust contracts, we have a few scenarios to consider:

1. When a public function has an internal implementation (like transfer_ownership), we can use the fn_name_internal suffix pattern. This maintains clarity while following Rust conventions. We could also use do_fn_name. Which one do you like more (I prefer the latter, as it's shorter?

2. However, we also have internal functions meant for inheritance that don't have public counterparts (like _mint in ERC20). Simply removing the underscore could be misleading - developers might assume these functions are public since they don't follow the _internal/do_ pattern they see elsewhere in the codebase. Having a function like mint could also pose problems with inheritance, as the name might conflict with the public function version's name 🤔
   On the other hand, we don't want all internal functions to follow this convention - those functions that act like modifiers in Solidity (e.g. Ownable::only_owner) should be probably be left as-is, as they're clear enough (I like neither do_only_owner nor only_owner_internal).

Here's my proposal: Let's consistently use the same pattern for all internal functions that are likely to have a public counterpart. This approach would:

• Maintain clear visibility indicators like Solidity
• Follow Rust naming conventions
• Provide consistent patterns across our codebase
• Help developers quickly understand function visibility

What do you think about adopting this consistent pattern? It seems like a good balance between maintaining familiarity for Solidity developers while embracing Rust's conventions.

[0xNeshi]

We agreed to keep _ prefix for internal functions, until the moment stylus sdk with advanced inheritance is released.
Then we will reconsider.