Create Cadence Style Guide

[alilloig]

Context

Developers need better guidelines for how to write clean cadence code.

Definition of Done

Create a guide in the cadence section of the docs site that give recommendations for Cadence style

• line length
• function, field, and type comments (paremeters returns) /// (three slashes)
• indentation, spaces
• var/let type, spaces
• bracket spaces
• conditions and panic message formats
• comments on function interface or on function implementation
• Whitespace between code lines
• High level documentation at the beginning of contracts/transactions
• Contract, field, and function names and capitalization

PR Review

Who is your Code Partner - @joshuahannan
Who can provide external eyes - @satyamakgec

[alilloig]

@bluesign commented 6 days ago •
I think few important coding style questions are:

When to use panic?
When to return optional?
How to label functions? Where to use _ ?
When to use Struct vs Resource ?
Where to use access(contract) vs pub ?
How to link Resources correctly ? e.g. via multiple interface restrictions vs via multiple paths.
I think when repo is live, we should make each item as PR, then discuss on each PR if needed.
If we don't have opinion how it should be (more debatable), maybe we can start from an issue.