Making breaking changes to the project is currently allowed, but it is recommended to avoid doing so unless necessary. If breaking changes are made, they should be clearly documented in the commit messages and in the documentation to ensure that users are aware of the changes and can update their code accordingly. It is important to maintain clear communication with users and contributors about any changes that may affect them, especially if those changes are breaking.
- Overview of the language: https://odin-lang.org/docs/overview/
- Base Library Collection:
$HOME/Odin/base - Core Library Collection:
$HOME/Odin/core - Vendor Library Collection:
$HOME/Odin/vendor - Odin GitHub Repository: https://github.com/odin-lang/Odin
- When assigning values to a struct, Odin expects either names or no names, but not a mix of both. For example,
return Message{id = getNextMessageID(), type = type, timestamp = time.now(), pid = pid}andreturn Message{getNextMessageID(), type, time.now(), pid}are valid, whilereturn Message{getNextMessageID(), type, timestamp = time.now(), pid}is not valid and will result in a compilation error. - Variable declarations follow the syntax
name: type = value, where the type can be inferred from the value if it is not explicitly specified. For example,x := 5will infer thatxis of typeint, whiley: f32 = 3.14explicitly declares thatyis of typef32. If the type cannot be inferred from the value, it must be explicitly declared to avoid compilation errors. - For getting the length of an array, use
len(array). This includes strings, slices, and other array-like structures.
- Checking for compile errors:
odin check .
- Test files:
*_test.odin(e.g.,grid_test.odin) - Test command:
odin test .replace.with the specific file or directory you want to test as needed (e.g.,odin test grid_test.odin). - Use the built-in testing library from Odin.
import "core:testing"and any procedures must havet: ^testing.T,as the first parameter. - Use
assert(a == VALUE, "message that test failed")for assertions in tests, and provide a clear message that indicates what the expected value was and what the actual value is if the assertion fails.
All configuration keys use consistent naming and MUST be documented.