Rust General

Cursor-Regel für allgemeine Rust-Konventionen — breiter Basis-Baustein statt Framework-spezifischer Vorgaben.

Original-Beschreibung der Autoren: General Rust rules for safe, idiomatic application and library development

Die Regel

---
description: General Rust rules for safe, idiomatic application and library development
globs: ["**/*.rs", "Cargo.toml", "Cargo.lock"]
alwaysApply: false
---

# Rust General Rules

## Project Structure

- Keep crates focused and name modules by domain responsibility.
- Put reusable library code in `src/lib.rs` and binary entry points in `src/main.rs` or `src/bin/`.
- Keep public APIs small and documented.
- Use feature flags deliberately and document non-default features.
- Commit `Cargo.lock` for applications; follow the project convention for libraries.

## Ownership and Types

- Prefer borrowing over cloning when ownership is not needed.
- Use owned values at API boundaries when the callee must store data.
- Model domain states with enums and structs instead of strings or booleans.
- Use `Option<T>` for absence and `Result<T, E>` for fallible operations.
- Avoid `unwrap()` and `expect()` outside tests, examples, and process-startup invariants.

## Error Handling

- Use `thiserror` or project-standard custom errors for libraries.
- Use `anyhow` or project-standard context-rich errors for applications.
- Add context when crossing IO, network, database, or parsing boundaries.
- Do not discard errors with `_` unless explicitly documented.

## Concurrency and Async

- Use `Send` and `Sync` boundaries intentionally.
- Prefer message passing or owned task inputs for async work.
- Do not hold blocking locks across `.await`.
- Use `tokio::task::spawn_blocking` or equivalent for blocking CPU or IO in async applications.
- Propagate cancellation through futures rather than hiding it in detached tasks.

## Testing and Quality

- Run `cargo fmt` and `cargo clippy` before delivery.
- Add unit tests for pure logic and integration tests for public behavior.
- Use property tests for parsers, serializers, and state machines when useful.
- Use benchmarks only after identifying a real performance question.

## Common Mistakes

- Do not fight the borrow checker by adding unnecessary `Arc<Mutex<_>>`.
- Do not expose internal module structure through public APIs by accident.
- Do not allocate in hot loops without measuring.
- Do not use unsafe code unless the invariant is documented and tested.

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Wie die einfache „Rust“-Regel liefert auch „Rust General“ grundlegende Konventionen für Rust-Code — Stil, Idiome, Umgang mit Error-Handling und Ownership. Der Namenszusatz „General“ deutet darauf hin, dass sie bewusst allgemein gehalten ist und nicht auf ein bestimmtes Rust-Framework oder einen bestimmten Anwendungsfall zugeschnitten ist, sondern als breite Basis für beliebige Rust-Projekte dient. Sinnvoll als Startpunkt in .cursor/rules, wenn noch keine projektspezifischeren Rust-Regeln vorhanden sind. Da der Funktionsumfang dem der „Rust“-Regel ähnelt, lohnt sich vor der Nutzung ein kurzer Vergleich beider Dateien, um Redundanz oder widersprüchliche Vorgaben zu vermeiden.

Praxis-Tipp

Vor dem Einsatz mit der einfachen „Rust“-Regel vergleichen, um doppelte oder widersprüchliche Vorgaben in .cursor/rules zu vermeiden — meist reicht eine der beiden.

Siehe auch

• Anti Overengineering

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …