Was & Warum
branching.ex:68-77 und line_patterns.ex:67-82 haben zwei verhaltens-identische private Funktionen max_nesting_depth/1. Beide zählen die maximale Klammerverschachtelung via String.graphemes |> Enum.reduce({0, 0}, ...) über die Sets (/[/{ und )/]/}, mit max(depth - 1, 0) als Untergrenze. Nur Variablennamen und Formatierung unterscheiden sich.
Verifiziert: gleiche Klammer-Sets, gleiche Untergrenze, gleiches Reduce-Muster → byte-äquivalentes Verhalten.
Umsetzung
- Helper in ein geteiltes Modul ziehen (z.B.
CodeQA.Math oder neues CodeQA.Metrics.Helpers).
- Beide Call-Sites darauf umstellen.
- Bestehende Tests von
branching und line_patterns decken die Call-Sites ab — sollten unverändert grün bleiben.
Nutzen
~15 Zeilen Duplikation weg, Klammertiefe-Logik an einer Stelle. Niedriges Risiko.
Was & Warum
branching.ex:68-77undline_patterns.ex:67-82haben zwei verhaltens-identische private Funktionenmax_nesting_depth/1. Beide zählen die maximale Klammerverschachtelung viaString.graphemes |> Enum.reduce({0, 0}, ...)über die Sets(/[/{und)/]/}, mitmax(depth - 1, 0)als Untergrenze. Nur Variablennamen und Formatierung unterscheiden sich.Verifiziert: gleiche Klammer-Sets, gleiche Untergrenze, gleiches Reduce-Muster → byte-äquivalentes Verhalten.
Umsetzung
CodeQA.Mathoder neuesCodeQA.Metrics.Helpers).branchingundline_patternsdecken die Call-Sites ab — sollten unverändert grün bleiben.Nutzen
~15 Zeilen Duplikation weg, Klammertiefe-Logik an einer Stelle. Niedriges Risiko.