Rust Code Reviewer

Rust Code Reviewer

Perform comprehensive code reviews for Rust code with focus on safety, correctness, idiomatic patterns, and performance.

Review Process

Follow this systematic review process:

1. Initial Assessment

Read the code thoroughly to understand:

• Purpose and functionality
• Architecture and design patterns
• Dependencies and external crates
• Test coverage

2. Safety & Correctness Analysis

Unsafe Code:

• Identify all unsafe blocks and justify their necessity
• Verify unsafe code upholds Rust's safety invariants
• Check for safer alternatives (e.g., safe abstractions from std/crates)
• Ensure proper documentation of safety contracts

Memory Safety:

• Verify borrow checker compliance
• Check for potential dangling references
• Identify improper lifetime annotations
• Look for unnecessary clone() or copy() operations
• Detect potential memory leaks (Rc cycles, forgotten Boxes)

Concurrency:

• Verify thread safety (Send/Sync bounds)
• Check for data races or race conditions
• Identify deadlock potential with Mutex/RwLock
• Review channel usage patterns
• Ensure proper use of Arc vs Rc

Error Handling:

• Verify all Results are handled (no ignored ? or unwrap() in production)
• Check for appropriate error types
• Evaluate error propagation patterns
• Suggest thiserror or anyhow where beneficial
• Avoid panics in library code

3. Idiomatic Rust Review

Ownership & Borrowing:

• Prefer borrowing over cloning when possible
• Use &str over &String and &[T] over &Vec<T>
• Apply smart pointer types appropriately (Box, Rc, Arc)
• Suggest lifetimes only when necessary

Type System:

• Use newtypes for type safety
• Leverage the type system (enums for state machines)
• Apply appropriate visibility modifiers
• Use #[non_exhaustive] for public enums
• Prefer impl Trait over boxed trait objects when possible

Iterators & Functional Patterns:

• Replace explicit loops with iterator chains where clearer
• Use .filter().map() over manual accumulation
• Apply collect(), fold(), find() appropriately
• Avoid unnecessary allocations in hot paths

API Design:

• Follow naming conventions (snake_case, UpperCamelCase)
• Use builder patterns for complex initialization
• Implement appropriate traits (Debug, Display, Clone, etc.)
• Make intentional choices about Copy vs Clone
• Consider #[must_use] for important return values

Pattern Matching:

• Use exhaustive matching
• Prefer if let and while let for single patterns
• Apply match guards when appropriate
• Avoid nested matches (consider early returns)

4. Performance Review

Allocations:

• Identify unnecessary heap allocations
• Suggest Cow for conditional ownership
• Use stack allocation where possible
• Consider reusing buffers

Algorithmic Efficiency:

• Check time complexity
• Identify N+1 query patterns
• Review data structure choices (HashMap vs BTreeMap)
• Look for premature optimization

Compilation:

• Check for excessive monomorphization
• Identify overly generic functions
• Consider trait objects for compile time reduction

5. Code Quality

Documentation:

• Ensure public APIs have doc comments
• Verify examples in doc tests compile
• Check for outdated comments
• Suggest #![warn(missing_docs)] for libraries

Testing:

• Verify test coverage for critical paths
• Check for edge cases
• Suggest property-based testing (proptest) where appropriate
• Review test organization and naming

Maintainability:

• Check module organization
• Identify code duplication
• Suggest macros only when they reduce complexity
• Evaluate readability vs performance tradeoffs

Dependencies:

• Check for outdated crates
• Identify unnecessary dependencies
• Suggest lighter alternatives when available
• Verify feature flags usage

6. Rust Edition & Clippy

Edition Features:

• Suggest newer edition features when beneficial (2021 resolver, disjoint capture)
• Check edition compatibility

Clippy Lints:

• Run cargo clippy -- -W clippy::all -W clippy::pedantic
• Address high-priority lints
• Justify any allowed lints

Review Output Format

Structure review feedback as:

Critical Issues (must fix):

• Safety violations
• Correctness bugs
• Security vulnerabilities

Important Improvements (should fix):

• Idiomatic violations
• Performance problems
• Error handling gaps

Suggestions (nice to have):

• Readability improvements
• Documentation enhancements
• Alternative approaches

For each issue:

1. Location: File and line number
2. Issue: Clear description
3. Why: Explanation of the problem
4. Fix: Concrete code suggestion or approach

Common Pitfalls to Check

• unwrap() / expect() in library code
• Missing #[derive(Debug)] on public types
• Public struct fields (prefer accessors)
• Unnecessary mut bindings
• Inefficient string building (use format! or push_str)
• to_string() when to_owned() suffices
• Blocking operations in async contexts
• Missing bounds checks before indexing
• Integer overflow in release mode
• Unvalidated user input

Reference Materials

For detailed patterns and anti-patterns, see:

• references/rust_patterns.md - Common idiomatic patterns
• references/anti_patterns.md - Patterns to avoid
• references/performance_tips.md - Performance optimization guide

Review Tone

Maintain a constructive tone:

• Acknowledge good practices found
• Explain reasoning, not just rules
• Provide learning opportunities
• Balance perfectionism with pragmatism
• Respect project constraints