Repository navigation
ToPascalCase/ToCamelCase change their own output when run again on adjacent one-letter words: "vector x y" → "VectorXY" → "VectorXy" #95
Description
Activity
Triage
- Category: Bug
- Priority: Medium.
ToPascalCaseandToCamelCaseare not idempotent for adjacent one-letter words (VectorXY→VectorXy), so identifiers drift across repeated normalisation. This is an edge case, but a real one for code generators. - Area / suggested owner:
CaseConverter.cs:ToPascalCase,LowercaseAllCapsWords(from Whether an all-caps word is normalized or kept as an acronym depends on what else is in the string #72), and the acronym-tail rule inIsWordBoundary. - Duplicates / in progress: Not a duplicate. It is a side effect of Whether an all-caps word is normalized or kept as an acronym depends on what else is in the string #72's all-caps normalisation. The open PRs Keep the letter after a typographic apostrophe lowercase in ToTitleCase [patch] #91–Keep an all-caps word containing ß in one piece, so ToMacroCase is idempotent [patch] #94 all touch idempotence and acronym handling in the same file (possessives, ß, apostrophes), but none of them covers one-letter runs. Expect conflicts, so land this after those PRs or rebase onto them.
- Suggested next step: Decide whether the
vector_x_y→vector_xyfold is acceptable and document it. Then add theToPascalCase().ToPascalCase()idempotence tests from the issue.
Generated by Claude Code
Decision (maintainer, 2026-09-28)
- Take the suggested option: when a one-letter word follows another one-letter word, lowercase it. The first pass then gives
"vector x y"→"VectorXy", which is stable on re-conversion. - The
vector_x_y→ Pascal → snake →vector_xyfold is accepted. Document it in the README and the XML remarks as a known, deliberate loss of the boundary between adjacent one-letter words.
Next reader: implement the lowercase rule in
ToPascalCase/ToCamelCase. Add the idempotence tests for"vector x y","a b c"and"x_y", plus a pinned expectation that"vector_x_y".ToPascalCase().ToSnakeCase() == "vector_xy", and document the fold. Land it after, or rebase onto, the open PRs #91–#94 that touch the same code.
Generated by Claude Code
- Take the suggested option: when a one-letter word follows another one-letter word, lowercase it. The first pass then gives
What's wrong
Adjacent one-letter words turn into a run of capitals in PascalCase:
"vector x y"→"VectorXY","a b c"→"ABC","x_y"→"XY". When that output is converted again,IsWordBoundaryreads the run as a single all-caps word, andLowercaseAllCapsWords(the per-word all-caps normalisation added for #72) lowercases it. So the converters don't return their own output unchanged, and round trips silently lose word boundaries.Relevant code, all in
CaseConverter/CaseConverter.cs:ToPascalCase(~L370)LowercaseAllCapsWords(~L240)IsWordBoundary(~L150)Reproduction
Against the net10.0 build of HEAD (1c1c555):
A single one-letter word does survive, because the next letter is lowercase and the acronym-tail rule applies:
"get_a_value"→"GetAValue"→"get_a_value".Why it matters
Identifiers like
coord_x_y,matrix_m_nandget_x_yare common. A code generator or rename tool that normalises names more than once, or goes snake → Pascal → snake, gets different identifiers on each pass:VectorXYbecomesVectorXy, andcoord_x_ybecomescoord_xy.Suggested fix / acceptance criteria
ToPascalCaseandToCamelCaseshould not produce output they would convert differently on a second pass. One option: when a one-letter word follows another one-letter word, lowercase it, so"vector x y"→"VectorXy"on the first pass. That output is stable, althoughvector_x_y→ Pascal → snake would still come back asvector_xy. If that fold is acceptable, document it.Tests:
s.ToPascalCase().ToPascalCase() == s.ToPascalCase(), and the same forToCamelCase, for"vector x y","a b c"and"x_y""vector_x_y".ToPascalCase().ToSnakeCase()