Skip to content

refactor: reduce cyclomatic complexity in the mesh I/O readers and mutation routines (radon D/E) #264

Description

@domattioli

Finding

A radon cc scan of src/chilmesh reports eleven functions at rank D or E (complexity 21 or higher). Ranked worst first:

Rank Complexity Location
E 36 gmsh_io._read_msh_v4_1
E 34 fort14_io.read_fort14_raw
E 32 _vendor_admesh_truss.distmesh2d_warmstart
D 26 fort13_io.read_fort13
D 25 gmsh_io._read_msh_v2_2
D 24 CHILmesh.direct_smoother
D 22 CHILmesh.read_from_fort14
D 22 mutations.MutableMesh.collapse_edge
D 22 summary_io._summary_from_file
D 21 mutations.MutableMesh.repeel_local
D 21 write_fort14

The pattern is consistent: the format readers each parse a header, then a nodes block, then an elements block, then an optional boundary block, all inline in one function with interleaved validation. That is why each reader also accumulates unused-variable warnings — several int(...) parses exist purely to raise ValueError for the surrounding except to convert into a GmshParseError, so the assigned name is never read.

Why this is not a mechanical fix

Splitting a reader into per-section helpers changes where exceptions originate and which partial state is visible at each failure point. Since fort.14 round-trip fidelity is a hard compatibility constraint, any split needs round-trip tests over the full fixture corpus to prove byte-identical output before and after, not just a green unit suite.

Suggested approach

Take one function at a time, highest complexity first, and for each:

  1. Extract the per-section parse into a private helper that raises the same error type.
  2. Give the helper direct tests, including malformed-input cases.
  3. Confirm round-trip identity on all four fixtures (annulus, donut, block_o, structured) plus the fort.14 reference corpus.

_vendor_admesh_truss.distmesh2d_warmstart should be left alone — it is a vendored copy and should track upstream rather than diverge.

Scope guard

No change to _skeletonize() behavior, public API signatures, fort.14 I/O semantics, or adjacency invariants.

[model: claude-opus, repo: CHILmesh, session: dev-cleanup sweep]

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions