Wise Token

Coding Standards

  • 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 style guide section of in the official Solidity 0.7.2 documentation.
  • All public interfaces (at a minimum) should be annotated using the NatSpec format.
  • 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.