Naming, Imports, and Prelude Policy

Rule

Use idiomatic Rust casing, explicit module-level imports grouped by rustfmt, and no broad crate prelude by default.

Why

Predictable names and imports make code easy to scan without hiding dependencies behind unusual casing or broad glob imports.

Do

• Use Rust-style acronym casing: HttpClient, UrlParser, JsonBody, ApiToken.
• Use SCREAMING_SNAKE_CASE for constants and statics.
• Keep imports at module scope and let rustfmt group them.
• Use as _ for extension traits imported only to enable methods.
• Follow conversions and getters for accessor and conversion names.
• Add a prelude only when a broad ecosystem crate makes users import many commonly paired traits and types.

Avoid

• Do not use names such as HTTPClient or URLParser.
• Do not use broad production glob imports.
• Do not add a prelude to a small crate or ordinary application.
• Do not preserve external naming conventions inside Rust identifiers when a boundary conversion is clearer.

Example

#![allow(unused)]
fn main() {
use std::path::Path;

use anyhow::{Context as _, Result};

use crate::{Config, RunId};

pub fn load_config(path: &Path, run_id: RunId) -> Result<Config> {
    Config::load(path).with_context(|| format!("loading config for run {run_id}"))
}
}

Exceptions

• Use wildcard imports in tests, test support, or intentional third-party prelude APIs.
• Preserve uppercase spellings required by generated code, protocols, or wire formats.