Fold the two NormalizePropertyName helpers, and stop decoration-only keys being silently renamed

[matt-edmondson]

Picks up the last outstanding item noted on #113 — "the two near-duplicate NormalizePropertyName helpers are untouched" — and, in doing it, turns up a data-loss bug that is already reachable on main.

Refs #113. This does not close it: the PropertyMerger fuzzy-ranking half is still open and still waiting on the judgement call recorded there. Only the helper fold is done here.

The fold

NameStandardizer and PropertyMerger each carried their own NormalizePropertyName, and the copies had drifted. The standardizer's:

• lower-cased without trimming
• compared its prefix and suffix culture-sensitively (StartsWith(string) / EndsWith(string))
• replaced only the space character, so tabs and newlines survived

Measured over a 30-key corpus, the two disagreed on 15. A sample:

key	NameStandardizer	PropertyMerger
\ttitle	\ttitle	title
" meta_description "	meta_description	description
" user_name_value "	user_name_value	name
" post_headline "	post_headline	headline
" page_ "	page	(empty)

Both now call one PropertyNameNormalizer, which takes the merger's behaviour on every point of difference — it is the more robust of the two: Trim() covers all whitespace rather than the space alone, ordinal comparison is correct for fixed ASCII affix tokens, and Split/Join collapses separator runs in one pass.

The bug the fold surfaced

A key made only of decoration — page_, _value, _, page__value, meta_ — normalizes to the empty string. Every string contains the empty string, so the containment tests in both classes admit such a key against the entire candidate set, and it is then renamed to, or merged into, whichever candidate ranks first.

Verified on main, before any change here:

NameStandardizer.StandardizePropertyNames({"page_": v})   ->  {"title": v}
NameStandardizer.StandardizePropertyNames({"_value": v})  ->  {"title": v}
PropertyMerger.MergeSimilarProperties({"page_", "description"}, Maximum)
                                                          ->  merged into "description"

The value is silently attributed to an unrelated property — the one thing a round-tripping frontmatter library must not do.

Padding was masking part of it by accident: " page_ " survived only because the standardizer's missing trim blocked the prefix strip, while bare "page_" did not. Folding the helpers without fixing this would have made the failure uniform rather than removing it, so both call sites now treat an empty normalized form as "nothing to match on" and leave the key alone.

Tests

Three regression tests, each of which fails against the previous implementation (verified by reverting the two source files and re-running — 3 failed, 134 passed):

• StandardizePropertyNames_PreservesDecorationOnlyKeys
• MergeSimilarProperties_DoesNotMergeDecorationOnlyKeyIntoAnother
• StandardizePropertyNames_TreatsPaddedAndUnpaddedKeysAlike

Plus five characterization tests pinning the shared normalizer's semantics.

The padded/bare test asserts over the decision rather than the literal spelling, because an unmatched key is preserved verbatim — padding included — which is correct for a round-tripping library.

Full suite: 137 passed, 0 failed (129 pre-existing, unchanged).

Scope notes

• No public API change; both classes and the new one are internal.
• One pre-existing looseness is deliberately not touched: a key normalizing to a single character still containment-matches any standard property containing it, so meta_x_field → x → next. That is main's behaviour for the unpadded form already; this PR only makes the padded form agree with it. Narrowing that heuristic is a separate behaviour judgement.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UJa1Uvm6PDR74cLBoE4PMY

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud