You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tidy up the code by deleting old, unused code and fixing compiler hints/warnings. Suppress false positive ones, if needed.
2
-
When do general code review, check adherence to the best coding practices on Rust. Also, pay a special attention on potential performance/resource overuse issues.
1
+
Review the code changes in the current branch, ensuring they adhere to the coding standards outlined in CLAUDE.md.
@@ -314,3 +221,57 @@ This architecture allows rules like MD013 to work efficiently with raw text whil
314
221
1. Create conversion functions in `quickmark_config`
315
222
2. Add new public functions following the pattern of `parse_toml_config`
316
223
3. Both CLI and server applications can immediately use the new format
224
+
225
+
## Code Guidelines
226
+
227
+
### General principles
228
+
229
+
1.**Follow idiomatic Rust**: Use the latest Rust best practices and conventions. Code should feel natural to an experienced Rust developer.
230
+
2.**No unsafe unless required**: Do not use unsafe blocks unless absolutely necessary for performance or interoperability. If used, justify with a comment and encapsulate safely.
231
+
3.**Zero compiler warnings**:
232
+
- Code must compile with `#![deny(warnings)]`.
233
+
- Suppress only known false positives with clearly scoped `#[allow(...)]` attributes and documented reasons.
234
+
4.**Speed over memory**:
235
+
- Optimize for CPU performance, even at the cost of increased memory usage.
236
+
- Avoid unnecessary allocations, but favor speed in algorithms and data access patterns.
237
+
5.**Cloning is expensive**: Avoid cloning (`.clone()`) unless it is proven to be more efficient than passing a reference or performing in-place mutation.
238
+
6.**Use modern language features**:
239
+
- Prefer `let else`, `if let`, match ergonomics, Iterator combinators, `?` operator, and Result-based error handling.
240
+
- Consider `Cow` or `Arc` where applicable to avoid unnecessary clones.
241
+
242
+
### Optimization practices
243
+
244
+
1.**Prefer move semantics** when data is no longer needed.
245
+
2.**Use references wisely**: Use `&T` or `&mut T` rather than `T` or `T.clone()` when ownership is not required.
246
+
3.**Inline strategically**: Inline functions where beneficial using `#[inline]` (but measure if in doubt).
247
+
4.**Use zero-cost abstractions**: From the standard library or crates like `itertools`, `smallvec`, `rayon` (for parallelism), etc.
248
+
5.**Choose fast data structures**: For hot paths, prefer faster data structures, even if more memory is consumed (e.g., `HashMap` over `BTreeMap` when ordering is unnecessary).
249
+
250
+
### Safety and correctness
251
+
252
+
1.**Use strong typing**: Use the type system to enforce invariants.
253
+
2.**Avoid panics**: In library code (`unwrap()`, `expect()`) unless in clearly unreachable branches.
254
+
3.**Mark important results**: Use `#[must_use]` to mark important results when appropriate.
255
+
4.**Document assumptions**: Document all `TODO`, `FIXME`, and assumptions in code.
1.**Use Clippy lints**: That enforce performance best practices (e.g., `clippy::redundant_clone`, `clippy::needless_collect`, `clippy::manual_memcpy`, etc.)
269
+
2.**Use performance attributes**: `#[inline(always)]`, `#[cold]`, or `#[no_mangle]` where profiling/FFI suggests it makes sense — but only after benchmarking.
270
+
271
+
### Testing & Validation
272
+
273
+
**Tests must**:
274
+
275
+
1.**Cover edge cases**: And performance regressions.
276
+
2.**Use `#[should_panic]`**: Where panics are expected.
277
+
3.**Prefer property-based testing**: Use `proptest` or fuzzing where inputs are highly variable.
0 commit comments