Option and Result Idioms

Rule

Use simple combinators for local transformations and explicit branching when absence or failure carries behavior, side effects, context, or recovery.

Why

Short combinators keep linear transformations compact, while behavior-bearing decisions need visible control flow.

Do

• Use ? to propagate within the same Result or Option shape.
• Convert required optional values with ok_or for cheap errors and ok_or_else for computed errors.
• Use map, filter, and unwrap_or_else for short side-effect-free transforms.
• Use map_err for typed conversion that retains the source.
• Use transpose to turn Option<Result<T, E>> into Result<Option<T>, E>.
• Use explicit branching for logging, metrics, cleanup, retries, or recovery.
• Add context according to error propagation.

Avoid

• Do not chain combinators past easy readability.
• Do not hide side effects in map, and_then, or_else, or inspect.
• Do not call .ok() unless detailed failure intentionally becomes absence.
• Do not eagerly evaluate an expensive fallback with unwrap_or.
• Do not use unwrap_or_default when absence is a domain error.
• Do not check is_some and then unwrap.

Example

#![allow(unused)]
fn main() {
pub fn build_request(input: &Input) -> Result<Request, Error> {
    let id = input.id().ok_or(Error::MissingId)?;

    let mode = input
        .mode()
        .map(Mode::parse)
        .transpose()?
        .unwrap_or_else(Mode::default);

    let timeout = match input.timeout_ms() {
        Some(0) => return Err(Error::InvalidTimeout),
        Some(ms) => Timeout::from_millis(ms)?,
        None => Timeout::default(),
    };

    Ok(Request::new(id, mode, timeout))
}
}

Exceptions

• Use a longer chain when every step is pure and clearly named.
• Use match for a simple case when exhaustiveness documents the domain.
• Use .ok() at an external boundary where absence is the deliberate projection.