A very interesting discussion is happening on Open Zeppelin’s Github:
TL;DR : Should Cairo contracts use camelCase or snake_case ?
Feel free to engage in discussion there, or here 
8 Likes
I wanted to give an overview of the issue in a way that’s as balanced as possible. From my discussion with @martriay it’s clear it’s not a matter of only naming (a.k.a. 
case vs 
case) but more broad compatibility with EIP-20 and other EIPs. If we decide to use snake case we should not name our contracts after the EIP they translate but something else. If we decide to use camel case we should also follow the full spec and use uint256 for amounts and have exactly the same signature.
I voted for camel case for the following reasons:
- makes it easier for contracts to deploy on StarkNet using warp,
- once indexers integrate with StarkNet, it means we can leverage the existing libraries of subgraphs (like the one provided by Open Zeppelin),
- Frontends only need to update calls at the lowest level, they won’t have to manually change the name of the method they’re invoking if they’re calling StarkNet.
The price to pay for all these goodies is some uglyness in the function name.
My proposal in the proposal is to use camel case only for @external functions:
- technically consistent with Cairo’s standard library, since it doesn’t export any external function.
- becomes obvious when you’re calling an external function from within your smart contracts.
11 Likes
As @fracek points out, the github discussion linked above is not about Cairo’s style but a more broader interoperability discussion.
I do think though, that if Cairo decides to move to camelCase (which is something several projects such as Vyper did, despite being python-inspired for the same interop reasons), then interoperability might be slightly easier down the road, considering most standards are EVM compatible.
9 Likes
Cool perspective, thank you - I have changed the topic name to make it more accurate.
7 Likes