Guideline Idea Tracker

@ralfbiedert is already working on this.

Since Aug 23, 2025.

> Note, names and guidelines are tentative, this is mainly a braindump of my (@ralfbiedert) collection of notes from reviews and conversations:

Common / Unsorted
- [ ] M-NO-FQP - Don't FQP paths in code (TODO: should be clippy lint already, probably just update other guideline)
- [ ] M-LOG-ERRORS-XXX - Some guideline where to approach logging (relative to error position, only stack upmost?)
- [ ] M-TODO-UNREACHABLE-UNIMPLEMENTED - When are they fine to have?
- [ ] M-TYPE-DEFAULT-NEW - `::default()` implies `::new()` on public types
- [ ] M-URI - What to use for Uri and URL?
- [ ] M-MUST-NOT-PANIC - Outline situations where panics must not occur
- File parsers, protocol parsers, user input parsers should return errors when encountering unexpected input values.
- All I/O handling should return errors when encountering I/O problems and not panic
- [ ] M-META-DESIGN-FOR-USERS(?) - As a library author you should do the hard thing that your users have it easy, not other way around. Esp. don't take shortcuts that significantly limit your user's ability to use your crate.
- [ ] `mod.rs` over `foo.rs` + `foo/`?
- [ ] Add rule that projects must have some command that runs "just like CI" to avoid wasting hours to rerun the same things again and again until some arcane test maybe passes

Performance
- [ ] Use of `CompactString` and friends.

Other areas that potentially need some guidelines:

- [ ] M-TESTABLE - Making components/designs so they can be used in tests (creating mocks, fakes, etc)

Ideas on improving AI efficacy:

- [ ] Keep designs simple and verbose over intricate
- [ ] Design for concrete types
- [ ] Design avoiding lifetimes
- [ ] Encourage smaller files and clean interfaces
- [ ] Keep / request a structured type / project layout file (maybe not?)