Skip to content

Latest commit

 

History

History
100 lines (67 loc) · 2.4 KB

File metadata and controls

100 lines (67 loc) · 2.4 KB

Rust Style Guide for Vector

**Note: ** This is a draft document primarily intended for AI agents (like Claude) to understand Vector's Rust coding conventions. These guidelines help ensure consistent code generation and modifications.

This document outlines Rust coding conventions and patterns for Vector development.

Import Statements (use)

All use statements must be at the top of the file/module or at the top of mod tests. This is for consistency.

Correct:

use std::time::Duration;
use governor::clock;
use crate::config::TransformConfig;

fn my_function() {
    // function code
}

Incorrect:

fn my_function() {
    use std::time::Duration;  // WRONG; Do not insert `use` inside functions
    // function code
}

Organization:

  • Group imports: std → external crates → internal (crate::)
  • Use rustfmt to automatically organize them: make fmt

Logging Style

Always use the Tracing crate's key/value style:

Correct:

warn!(message = "Failed to merge value.", %error);
info!(message = "Processing batch.", batch_size, internal_log_rate_secs = 1);

Incorrect:

warn!("Failed to merge value: {}.", err);  // Don't do this

Rules:

  • Events should be capitalized and end with a period
  • Use error (not e or err) for error values
  • Prefer Display over Debug: %error not ?error
  • Key/value pairs provide structured logging

String Formatting

Prefer inline variable syntax in format strings (Rust 1.58+).

Correct:

format!("Error: {err}");
println!("Processing {count} items");

Incorrect:

format!("Error: {}", err);      // Unnecessary positional argument
println!("Processing {} items", count);

Why: Inline syntax is more readable and reduces mistakes with argument ordering.

Panics

Code in Vector should NOT panic under normal circumstances.

  • Panics are only acceptable when assumptions about internal state are violated (indicating a bug)
  • All potential panics MUST be documented in function documentation
  • Prefer Result<T, E> and proper error handling

Feature Flags

New components (sources, sinks, transforms) must be behind feature flags:

# Build only specific component for faster iteration
cargo test --lib --no-default-features --features sinks-console sinks::console

See features section in Cargo.toml for examples.