Name Consistencies Between JS vs. Rust

[idea404]

It came to our (Pagoda DevRel) attention that naming conventions for functions differ between JS (camelCase) and Rust (snake_case). This inconsistency will lead to extra work for existing dApps that listen to events on-chain searching for function names, such as ft_transfer, to add search for camelCase function names.

This is not really the best solution, as new languages will probably also have SDKs for NEAR in the future, and they all come with their own casing convention for function names.

We'd propose adding a standard for naming convention of smart contract functions and have SDKs preferably support this auto-conversion (#136).

What do you guys think?

[frol]

I would like to suggest embracing naming conventions for the smart contract functions to enable better interoperability between the contracts written in different languages. Our NEPs already defined interfaces in snake_case and I suggest we stick to it.

At the same time, I would like to suggest that we don't break the programming language conventions, so the code does not look alien in the relevant ecosystem. In order to achieve that, I believe SDKs can handle auto-renaming and even allow people to provide custom aliases, e.g.:

@call('nft_mint')
nftMint({ token_id, metadata, receiver_id, perpetual_royalties }) {
   ...
}

[BenKurrek]

Thanks so much @frol ! do you have any opinions on parameters being passed into the functions? i.e you have:
nftMint({ token_id, metadata, receiver_id, perpetual_royalties }) {
but it could also be:
nftMint({ tokenId, metadata, receiverId, perpetualRoyalties }) {
I think anything public facing should be snake case as to promote interoperability but internal functions could take args as camel case. An example of this is the public facing function nft_mint I’ve defined here which has snake case args but it calls an internal method which takes camel case args as show here.

[frol]

Oh, good catch! Well, parameters are easy to match in JS:

@call('nft_mint')
nftMint({ token_id: tokenId, metadata: metadata, receiver_id: receiverId, perpetual_royalties: perpetualRoyalties }) {
   ...
}

It is a bit verbose, but should be quite straightforward for JS folks

[frol]

Though, nested parameters will become tedious to handle this way, so again, maybe consider some mapping. I love how serde in Rust allows one to #[serde(rename_all = "camelCase")]. Also given that we should validate the user input anyway, I would suggest we do some magic of automatic validation of the inputs using something like zod and then also remap (seems to only support through .transform at the moment) snake_case input fields to camelCase

[AustinBaggio]

Short-term summary:
The examples pertaining to standards (NFTs, FTs etc..) will use snake_case for all public interfaces such as method names and arguments. This is to maintain interoperability with other contracts and with the ecosystem as a whole. Other non-standard contracts will use camelCase.

We will continue to leave this thread open, and direct feedback here before we make a decision around converting case at compile-time