nx_dupfunc.nx

nx_dupfunc.nx -- WHICH FUNCTION BODIES ARE WRITTEN MORE THAN ONCE? ===== WHY THIS EXISTS ============================================ The tree already has nx_dup_source_check, and it is a good tool, but it answers a different question: it detects the SAME FILE existing in two source trees. It is file-level and cross-tree by construction, so it cannot see two files in the same directory that happen to contain the same function written twice. That gap is not theoretical. Building nx_gatescan and nx_gatequality I duplicated NINE functions between them -- the tree walk, file read, path join, the file-type predicates, the attribution rule -- while holding two tools designed to find exactly this class of problem. Nothing in the ecosystem could have told me. This organ closes that. ===== THE DESIGN DECISION THAT MAKES IT WORK ===================== ★NAMES ARE IGNORED. My nine duplicates were called gs_len and gq_len, gs_walk and gq_walk -- identical bodies behind different prefixes, which is what copying into a new file naturally produces. A detector keyed on names would have found none of them. So a function is reduced to its BODY, and the body alone decides identity. Normalisation before comparison, each for a reason: - comments stripped : a copied function usually keeps the code and rewrites the comment, or vice versa - whitespace collapsed : re-indentation is not a difference - the signature line dropped: that is where the name lives ===== RANKED BY COST, NOT BY COUNT =============================== Two copies of a 60-line walk are a different problem from two copies of a one-line helper. Severity is therefore (copies - 1) x body size: what you would actually save, and what is actually at risk of drifting apart. ⚠WHAT IT DOES NOT MEAN. Identical bodies are not automatically a defect. This tree deliberately keeps independent re-derivations of a rule inside gates, because a test that calls the code under test can only confirm self-consistency -- and that decision is what caught a dead primitive