What's the best practice for using env::log in smart-contracts?

Question

In Ethereum Events are clearly defined, each one is a data structure used to signal some action. In Near, env::log are messages. Example:

• In Ethereum we use logs for most of the token state changes
• NEP-21 dosn't say anything about logs.

Is there any point of using logs in near, except "debug" / return user information? Should logs be standarized ? Maybe it's better to have this discussion in some other place...?

Following on that: Transaction arguments are serialized and clearly visible. Is there any point to log transaction arguments? For example: in Ethereum token transfer functions, all arguments are recorded additionally in an event. There are few reasons for that:

1. With events we should be able to recreate a state of the contract;
2. it's more readable while browsing a blockchain. But in case of transfer, I don't think there is any added value, because we don't log anything else than the function arguments.

Answer 1

We haven't added analog of Ethereum events into NEAR yet. Contracts that want to signal about some event need to return it as part of the method result like here. Therefore our env::log is currently for informational purposes only and can be used for debugging and such.

In general, our contracts can choose how to serialize arguments, so it might be useful for the contract to log its own arguments since it might be using a complex serialization mechanism for them.

It might be useful to have logs for complex contracts with complex cross contract calls and callbacks so that it can inform the user how it arrived to a specific result.