[WIP] Consistent naming needed

[adlerjohn]

• Pointers (i.e. uint256 variables that point to a memory location) must have a Ptr suffix.
• Getters must have distinct names, otherwise it's easy to have a collision with the obvious variable name.

// is
let varNameTemp := Class.varName(object)
// should be
let varName := Class.getVarName(object)
// or
let varName := Class.get_varName(object)

• "Select" methods are opaque. Should be renamed to something like getFooAtProofIndex().
• Names of inputs to provers and verifiers should be consistent. inputProof should be reserved for a transaction proof for an input. For state elements, use something like stateElement.
• Pos -> Ptr consistent renaming.
• Function names that do an action (e.g. compute something) should have that action in their name.
• Use explicit Yul types.
• Use . in function names consistently. . should only be used for implicit substructures (e.g. a block in a transaction proof, since Yul+ currently doesn't support that).
• Use .. to scope top-level class methods (e.g. Class.method() becomes Class..method()), as a replacement for the usual :: scope operator.
• Namespace methods consistently and correctly (e.g. UTXO should not be under TransactionProof).
• Change call order for nested functions. May require using multiple return values. Note: major refactor.

// is
Class1.object2.method(object1, in2)
// should be
Class2.method(Class1.object2(object1), in2)
// or
Class2.method(object1, in2)

[SilentCicero]

I think I would like to leverage more dot notation here.

mstruct Something( someVar: uint256 )

Something.someVar.get(memPtr)

We can make a very small change to Yul+ to add this clarity here.

As for other selector methods, yes, I'm fine with changing it to getXThing vs selectXThing

The mstruct change along with the selector change should make getters more consistent across the board.

Can you expand on what you mean by stateElement here?

Fine with adding distinct Ptr suffix until we get mem pointer types and types in Yul+.

[adlerjohn]

Can you expand on what you mean by stateElement here?

State element as in, a UTXO, a deposit, or a root [UTXO]. These aren't part of an inclusion proof, and so should be named distinctly.

[SilentCicero]

• token -> tokenId where tokenId is used in all structs / events (e.e. Deposit) etc.

[SilentCicero]

• amount -> value or a consistent use of either term value or amount.

Suggestion: amount for proofs (i.e. UTXO / Deposit), value for everything else.

[adlerjohn]

Closing in favor of rewriting contracts for future versions in Solidity.