File structure: how to cut files and arrange folders for the reader
Question: how should content be cut into files, and files arranged in folders, so that nothing is held twice, each file does one thing, and a reader reaches what they need in few steps.
Steps: frame · review · state of the art · position · against · baseline · bibliography
Claims
| Claim | Grade | Where |
|---|---|---|
| Decompose by decisions likely to change; one role per module | supported with caveat | review.md 1 |
| Every clustering objective is a ratio of coupling to cohesion | supported with caveat | review.md 1, 2 |
| Developers do not balance cohesion and coupling the way recommenders do (100 systems, 29 developers) | measured | review.md 2 |
| Automated recovery averages 31-59 % MoJoFM against expert architectures | measured | state-of-the-art.md |
| Exact minimization of a hierarchy cost is NP-hard | proved (Dasgupta 2016) | position.md |
| Two levels beat three for search; the fastest layout had 32 items on one level | measured, on menus | against.md |
| Navigation follows scent; descriptive names are read faster | supported with caveat | review.md 6 |
| Folders must not import each other in a cycle | convention, untested | review.md 5 |
| Co-change and hotspot measures add what imports cannot see | supported with caveat | review.md 7 |
| Size confounds class-level metrics | measured | review.md 6 |
| Smaller files have fewer defects, so files should be split by length | not supported: defects grow more slowly than size | against.md |
| Linter defaults for file length differ by a factor of about 7 (300 against 2000 lines) | convention, untested | review.md 8, against.md |
| Tools enforce folder boundaries (Go internal/, Bazel visibility) | convention, untested | review.md 8, position.md |