Style

The rules the code in Bindrune follows. Setup, building and CI are in Development.

• No comments, doc-comments or docstrings. Intent lives in names and call flow; code that cannot be made self-evident that way is restructured, not annotated.
• Names have two to four concrete keywords and spell words out. A type is named after its file.
• The GTK application is grouped by the region of the window a module draws. Code shared by several regions lives in a top-level shared module instead of one region importing from another.
• The BlueZ crate is grouped by BlueZ concept and never depends on GTK.
• A region that grows large is split into Relm4 child components, not into files of loose helper functions. A child owns its state, receives new snapshots through its input messages and reports through its output messages; parents do not reach into child widgets. Repeated rows are factory components. Presentation logic that turns snapshots into text and view models stays as plain functions, so it is tested without GTK.
• Files stay between roughly 120 and 400 lines of code, not counting tests. Split a longer file at a real seam; merge a shorter one into its only user or into the module about the same concept.
• Show values as BlueZ and the kernel report them; do not reformat or capitalize them.
• Formatting is nightly rustfmt with imports grouped by crate (nix fmt).
• Markdown describes concepts and stable commands, so a fix or a small refactor does not have to update it. It does not name identifiers, source files, internal tasks, pipeline steps, dependency versions, or exact labels and layout of the interface. The code, --help and the rendered screenshots are the reference for those.