blob: a81a2ad04c9d3cc78c5b7fd2af38af1f0f06e740 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
# Repository Guidelines
## Project Structure & Module Organization
- `README.md`: Project overview and quick context.
- `assets/`: Images and brand assets
- `scripts/`: Helper tools and maintenance scripts.
## Coding Style & Naming Conventions
- Avoid duplication of code when the functions are larger than 5 lines.
- If possible, construct individual methods so that they can be unit tested. But only if it doesn't add too much boilerplate to the code base.
- Aim for at least 85% unit test coverage of all source code. The command to check the coverage is "mage coverage"
- Ensure that all unit tests pass before commiting any changes.
- Always run the gofumpt code reformatter on all go files modified.
- There should be no source code file larger than 1000 lines. If so, split it up into multiple.
- There should be no function larger then 50 lines. If so, refactor or split up into multiple smaller functions.
- Filenames: docs use `lowercase-with-dashes.md`; images use kebab‑case with size/purpose suffix (e.g., `hexai-small.png`).
- Code (when added): follow language idioms
- Any type with more than 3 methods should be in it's own source code file, whereas the filename contains the name of the type.
## Incrementing version
- Never draft a changelog entry
- Whenever incrementing the version, update the version number in the project, commit to git, tag the version and push to git.
- When a major feature was introduced, increment ?.X.?
- When only minor changes were done or only bugs were fixed, increment the version as ?.?.X
|
