rseng-defensive-codinglisted

# Defensive coding for research software Research code's worst bug is the one that runs to completion: the unit mismatch, the silently dropped rows, the column shifted by one, the reused random stream - producing plausible, wrong numbers that reach a paper. Defensive coding is the discipline of making wrongness LOUD: validate at boundaries, make implicit physics and randomness explicit, and prefer a crash today to a correction notice next year. It complements rseng-numerical-accuracy (float behavior) and feeds rseng-testing (the checks become tests). ## Validate at the boundaries Data enters code at boundaries - files, instruments, APIs, user parameters - and every boundary is a corruption opportunity: - Schema-check tabular data on ingest: expected columns, dtypes, units, ranges, allowed categories, uniqueness of keys (pandera-style declarative schemas for DataFrames; JSON Schema for configs and records). The schema is executable documentation of the data contract (rseng-data-management's data dictionary, enforced). - Sanity-check the science, not just the types: physical ranges (no negative concentrations, latitudes within +/-90), plausible magnitudes, conservation totals, expected row counts within tolerance of yesterday's. Domain assertions catch what dtype checks cannot. - Missing data is a decision, not a default: silent NaN propagation and silent row-dropping (the pandas default in many operations) are the classic silent killers - count and RE