Static Type Checking

Development Smart Contracts
1

What I mean by that is that we could require functions to always have annotations for args and return value.

ex.

def foo(bar: int) -> str:
    return f"{bar} piece"

Keep in mind that this change only applies to our linter and not the contract compiler.

From the linter code I read none of the two checks are implemented.

My Implementation:

Why should we have that?

  1. Improved Code Readability and Maintainability: Type annotations clarify the kind of data each function expects and returns, making our smart contracts easier to read and maintain. This clarity is especially beneficial for new developers joining our project or when revisiting older contracts for updates or audits.

  2. Enhanced Developer Tooling: Type annotations allow for better support from development tools, including smarter autocompletion, linting, and static analysis tools. These improvements can streamline the development process, reducing the time and effort required to write, debug, and review smart contracts.

  3. Consistency Across Contracts: Enforcing type annotations promotes a higher standard of coding practices and consistency across all smart contracts in our ecosystem. This standardization can make it easier to develop interoperable contracts and shared libraries.

3 Likes
2

That’s a great idea. It makes sense and we should use it.

Just two points:

  • Can you please replace the".format" with f-strings? It’s shorter and looks better imo.
  • Does this have performance implications on validating / executing contracts? It obviously validates contracts but only on submission right?

Thanks for this proposal and the implementation.

3

Does this support more complex types / interfaces / classes, or is it limited to basic types (str,int,float,dict,list) ?

also, are the types removed from the final compiled bytecode (they’re no longer needed at that point, right ?)

4

It just checks for argument and return annotations. The type doesn’t matter. @crosschainer correct?