This repository contains the default official module repository for BlueBuild. See ./modules/ for the module source code. See the website for module documentation. See How to make a custom module and Contributing for help with making custom modules and contributing.
These are general guidelines for writing official modules and their documentation to follow to keep a consistent style. Not all of these are to be mindlessly followed, especially the ones about grammar and writing style, but it's good to keep these in mind if you intend to contribute back upstream, so that your module doesn't feel out of place.
- Echo what you're doing on each step and on errors to help debugging.
- Don't echo blocks using "===", that is reserved for the code launching the modules.
- Use
snake_casefor functions and variables changed by the code. - Use
SCREAMING_SNAKE_CASEfor variables that are set once and stay unchanged.
Every public module should have a module.yml (reference) file for metadata and a README.md file for an in-depth description.
For the documentation of the module in README.md, the following guidelines apply:
- At the start of each paragraph, refer to the module using its name or with "the module", not "it" or "the script".
- Use passive grammar when talking about the user, i.e. "should be used", "can be configured", preferring references to what the module does, i.e. "This module downloads the answer to the ultimate question of life, the universe and everything..." instead of what the user does, i.e. "A user can configure this module to download 42".
- When talking about directories, postfix the file path with a slash, i.e.
/path/to/system/folder/orconfig/folder-in-user-repo/. When not talking about directories, do not postfix the file path with a slash, i.e./path/to/system/file.
For the short module description (shortdesc:), the following guidelines apply:
- The description should start with a phrase like "The glorb module reticulates splines" or "The tree module can be used to plant trees".