-
Notifications
You must be signed in to change notification settings - Fork 20
Coding style
Code is formatted with cargo fmt at the default settings except that use_small_heuristics = "Max" is set to make better use of the screen space.
The rustfmt.toml file in the repo root directory takes care of this.
Some of the huge tables could probably benefit from an exception to this formatting, to keep their rows as single lines, but that hasn't been done yet.
Short-term variables are often just named after their type or role.
If you have a key and its block, just call them "key" and "block"; no need to get creative.
A Validator is always called "vd", a ScopeContext is always called "sc", the &Everything reference is always called "data", etc.
Using consistent names for each type, and only using other names when it really matters, will lighten the cognitive load for the reader once they are familiar with these conventions.
Function arguments are in a fairly consistent order: key, block or bv, data, sc, vd where applicable, followed by any booleans.
Lookup functions take an Item and then a &str or Token. Validator functions start with the field name.
(These last two rules sometimes conflict, giving us vd.field_item(name, item) and data.verify_exists(item, name)).
The validator defines a feature for each game it supports (ck3 and vic3).
Normal cargo rules are that features must be additive, not conflicting, but we're breaking that rule.
You can turn on either ck3 or vic3 but not both.
This is done by deciding whether to build the ck3-tiger or the vic3-tiger crate. Each contains a binary and depends on the feature it needs.
The code should be buildable with either feature without emitting warnings. This can sometimes involve silencing warnings with #[allow(...)] attributes in the code.
use statements go at the top of the file, with imports from std in a separate block at the top, then imports from other crates, then crate:: imports from the validator itself.
Each block is sorted alphabetically.
Multiple items are combined into { lists } only when they come from the same module, with the exception of data modules which are combined to avoid repeating the #[cfg(feature = ...)] over and over.