Guideline Idea Tracker

Open
#16 0 comments 0 reactions 1 assignee View on GitHub

@ralfbiedert is already working on this.

Since Aug 23, 2025.

Assessment

This issue has not been assessed yet.

Description

request

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?)
Dominant language
Rust
Stars
200
Forks
25
Avg merge
3m
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/rust-guidelines

All issues in microsoft/rust-guidelines

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.