convert_case

Convert Rust strings between snake, kebab, camel, Pascal, title, and other cases

Library
Cargo
v0.11.0
164stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
45/100Fair
Development Activity48
Maintenance0
Community52
Maturity60
Momentum20

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
76/100Good
Architecture74
Code Quality76
Innovation70
Learning Curve82

convert_case is a Rust library for converting strings between naming conventions such as snake_case, kebab-case, camelCase, PascalCase, Title Case, and more. It works by splitting an input string on configurable word boundaries and re-joining the resulting words with a target case’s pattern and delimiter.

The crate is no_std compatible and highly customizable: boundaries, patterns, and delimiters can each be swapped out or combined via a Converter builder, while the ccase! macro offers a terse one-line API for the common case of converting a string without any custom configuration.

What You Get

  • The Casing trait adding .to_case(Case::X) and .from_case(Case::Y) methods directly on &str/String
  • A Converter builder for composing custom boundary/pattern/delimiter pipelines beyond the built-in cases
  • The ccase! macro for one-line conversions without importing Case/Casing explicitly
  • Fourteen+ built-in cases (Snake, Constant, Ada, Kebab, Cobol, Train, Flat, UpperFlat, Pascal, Camel, Upper, Lower, Title, Sentence)
  • no_std compatibility, making it usable in embedded or constrained Rust environments

Common Use Cases

  • Normalizing identifier names when generating code or config from a schema (e.g. converting API field names to snake_case for a Rust struct)
  • Converting slugs or URLs between kebab-case and human-readable Title Case for display
  • Building CLI tools (like the companion ccase binary) that reformat text case interactively
  • Adapting external API responses with inconsistent casing (camelCase JSON) to a project’s internal naming convention

Under The Hood

Architecture — The crate splits responsibilities across src/boundary.rs (566 lines, defines where a string should be split into words — e.g. LowerUpper, Underscore, Hyphen), src/pattern.rs (273 lines, defines how the resulting words are capitalized/joined), src/case.rs (410 lines, the Case enum mapping named cases to a boundary+pattern+delimiter combination), and src/converter.rs (436 lines, the Converter builder that lets users override the automatic boundary detection). src/lib.rs (804 lines) ties these together behind the Casing trait and the ccase!/case! macros, so a call like "my_var".to_case(Case::Camel) resolves to boundary-splitting the input into words, then applying the target case’s pattern.

Tech Stack — Pure Rust 2021 edition, no_std-compatible, with a single runtime dependency (unicode-segmentation for correct grapheme-aware word splitting). Dev dependencies include criterion for benchmarking (benches/convert.rs) and rstest for parameterized tests. Distributed via Nix flake (flake.nix/flake.lock) alongside the standard Cargo packaging, and a justfile for common dev tasks.

Code Quality — Tests live under tests/ using rstest for table-driven case coverage, and the README documents an active changelog spanning nine minor versions (0.7 through 0.11) with explicit breaking-change notes for each — a level of API-evolution discipline uncommon in small utility crates. Source files are focused and under 600 lines each, and the crate maintains #![no_std] compatibility as an explicit design constraint tested in CI.

API Design — The library exposes three levels of ergonomics: the single-line ccase! macro for the common case, the Casing trait for idiomatic .to_case() method chaining, and the Converter builder for advanced customization — letting simple call sites stay simple while still supporting fully custom boundary/pattern combinations for power users. The README’s changelog shows deliberate API simplification over time (e.g. reverting Pattern/Boundary from function-based back to enum-based APIs after user feedback).

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search