Rules

This page contains the rules that apply to ALL Drash Land software.

Required

The rules listed below are what it takes for Drash Land software to be included in an official release.

• Document the code
  • Drash Land follows Docmentation-Driven Development.
  • If you introduce a new API, make sure it is documented in https://github.com/drashland/website-v2.
  • Every function/method you write should have a doc block that makes sense to a developer AND a user. Users must be able to understand how the code works because Drash Land uses https://doc.deno.land for its API reference pages. If doc blocks do not make sense, then they must be reworded.
  • If you are having a difficult time writing documentation, hit up Eric or Ed in the Discord server for help.
  • Try not to use contractions. Given that Drash Land is open source, people all over the world can view the documentation. Therefore, it is best that words are spelled out entirely for clearer verbiage.
  • When writing example code blocks, make sure the example code has been tested end-to-end. Drash Land is known for its documentation and approachability.
  • Documentation will be reviewed/revised by Eric and/or Ed before being published.
  • Exceptions to this rule:
    • If there is a planned release date and doc blocks are taking up too much time, then a discussion should be raised to make an exception (and to make a Chore - Add doc blocks issue).
• Write unit and/or integration tests
  • Drash Land follows test-driven development.
  • If the code will be consumed by users, then write integration tests.
  • Exceptions to this rule:
    • If tests cannot pass without being merged into the base branch, then a discussion should be raised to make an exception.
• Use simple solutions
  • Do not introduce code bloat unless required. For example, do not solve a simple problem with a complex solution.
• Pass the CI
  • All pull requests are subject to the CI and will not be merged without passing it.
  • Exceptions to this rule:
    • If tests cannot pass without being merged into the base branch, then a discussion should be raised to make an exception.
• Format the code
  • Just run deno fmt and you are good to go! The CI will complain about this in case you forget.

Optional

• Linting code
  • Run deno lint to lint code
  • Regular deno lint checks are done in all codebases and issues are made to address lint issues.