Wise Token
  • Wise Token Docs
  • WISE (Ethereum)
    • Introduction
      • Purpose
      • WiseSoft, LLC
      • Motivations and Principles
    • WISE Contract Functionality
      • General Properties
        • Token Supply
      • Liquidity Transformer Epoch
        • Token Reservation
        • Daily LT Supply Schedule
        • Reservation Referrals
        • Referrer Bonuses
      • Circulation Epoch
        • Uniswap Provision
        • Wise Team Reimbursement
        • Minting Tokens
        • Supply Inflation
        • Staking
          • Opening Stakes
          • Shares and Interest
          • Scraping Stake Interest
          • Closing Stakes
          • Stake Referrals
        • Liquidity Provider Staking
      • ERC-20 Functionality
    • Wise Website
      • Referral Links
    • Conclusion
    • Acknowledgements
    • Availability
    • Appendicies
      • Terminology
      • Coding Standards
      • Source Code Audit
    • References
Powered by GitBook
On this page

Was this helpful?

  1. WISE (Ethereum)
  2. Appendicies

Coding Standards

PreviousTerminologyNextSource Code Audit

Last updated 3 years ago

Was this helpful?

  • The WISE contract is written entirely in Solidity and compiled with solc 0.7.2.

  • The code should adhere to the formats prescribed by the section of in the official .

  • All public interfaces (at a minimum) should be annotated using the .

  • Unit tests should provide 100% coverage of the source code. All conceivable edge and corner cases should be covered.

  • Function and variable names should convey their purpose and usage as clearly and tersely as possible, in plain English. Avoid using digits, unnecessary abbreviations, acronyms, shorthand, or slang.

  • Functions should be as short as is practical. They should do what their name implies, and not much else. A good rule of thumb is that a function should try to be viewable in its entirety on a typical monitor, at a typical font size, if at all possible.

  • Comments should be employed wisely. Don't comment to explain what code does. Good function and variable names will accomplish that. Rather, use comments to explain why something is coded a certain way, Use comments to explain any non-obvious technical points or decisions involved in a piece of code.

  • require() function calls should return a short but descriptive error message, always prefixed with "WISE: ".

  • Avoid duplicated code (don't repeat yourself).

  • Wherever possible and practical, write with gas efficiency as a priority. Some parts of the code may sacrifice minuscule gas efficiencies for various important reasons. When deemed to be of greater value, code legibility, clean architecture, and a straightforward and fully featured end-user experience should take priority over such tiny gas savings.

style guide
Solidity 0.7.2 documentation
NatSpec format