Skip to content

Latest commit

 

History

History
30 lines (21 loc) · 2.31 KB

CONTRIBUTING.md

File metadata and controls

30 lines (21 loc) · 2.31 KB
Raw

Contribution Guidelines

Thanks for considering to contribute to open hexagon 3.

General

To not waste any work on something that doesn't fit in the scope of the game, talk to us either on discord or in a feature request github issue first. The task will then be added to the prototype column of the board. If the suggestion gets accepted it will be added to the backlog, then you may assign yourself or get assigned to the task.

Code contributions must be tied to a task on the board.

Code Style

We use stylua to enforce our code style. Your editor likely has an extension for it as well. Stylua does not enforce the amount of blank lines between blocks of code. However you should put at least one blank line between function definitions. You may also put them elsewhere in the code where you see fit, but it is not required.

While it is not required at every point, functions and classes that are used many times in the code should be annotated with emmylua documentation comments. See this page for an example. Many language servers use it for auto completion, so it is very useful.

Design

The codebase is large and will only continue to grow. For this reason it is important to keep the following in mind:

  • Modularity. The game is split into multiple modules that ideally are responsible for a single task/feature/object. It should be easy to get an overview of what a module does quickly, that means that not only naming should be clear but a single file should also never become very large.
  • No globals. There should be no global variables besides the love variable. Globals are shared between modules and especially in a large codebase easily create hard to find issues.
  • Readability. When looking at a single module, one should be able to tell what it does easily given a bit of time. This entails intuitive variable naming, comments and minimal code. Code being readable and easy to understand is more important than micro-optimizations!
  • Performance. While micro-optimizations are to be avoided, structural decisions that have a great impact on performance should be made with it in mind.

Target branch

All pull requests should target the main branch.