functional-splitting-and-joining-codelisted

# Splitting and Joining Code ## Overview Given two pieces of functionality, should they be in the same place or separate places? The instinct to split is usually stronger than the instinct to join, and it is usually wrong: subdividing creates interfaces, and interfaces are where complexity lives. Subdivision also scatters what belonged together, so a reader must find all the pieces before understanding any of them. Bring code together when the pieces share information, are always used together, overlap conceptually, or cannot be understood apart. Split when one piece is general and the other is special, or when the two have genuinely separate reasons to change. ## When to use - A function is "too long" and the urge is to extract parts of it - Two modules are always changed in the same commit - General logic and one caller's special case share a body - A pipeline step is only ever called by one other step - Deciding whether a helper belongs in the file that uses it Not for: judging whether a module's interface is worth its cost, which is [functional-designing-deep-modules](../functional-designing-deep-modules/SKILL.md). ## Bring together when 1. **They share information.** Both need the same non-obvious fact: a format, an invariant, a set of thresholds. Splitting them makes that fact travel. 2. **They are always used together.** Every caller of one calls the other, in the same order, with the same values. 3. **They overlap conceptually.** A single sentence cov