3 ms·
One big reason is source control. Having many smaller files with well defined purpose reduces the number of edit collisions (merges) when working in teams. Als
by speed_spread 4y ago
One big reason is source control. Having many smaller files with well defined purpose reduces the number of edit collisions (merges) when working in teams.
Also, filenames and directories tree act as metadata to help create a mental map of the application. The filesystem is generally well represented in exploratory tools like file browser and IDE. While the same information can be encoded within the structure of a single file, one needs an editor that can parse and index the format, which may not be installed on every system.
- mbork_pl 4y agoWell, Git is pretty good at merging when the changes are in different places of the same file. Though your second point is a very good one. FWIW, sometimes when I worked on a really large file, I put some ^L's ("new page" characters) between logical sections, so that I could utilize Emacs' page movement commands.
- speed_spread 4y agoIt's not just git, it's pull requests and code reviews that block on concurrent file updates. The workflow friction multiplies with the number of devs sharing the same code area. Small files minimize this by making more granular work units.
- hbrn 4y ago> Also, filenames and directories tree act as metadata to help create a mental map of the application Correct. But this is an argument against splitting: once your folder structure reflects your mental model, you should no longer split, no matter how big individual files get. Splitting further will cause you to deviate from your mental model. Also, it seems like we're arguing against a strawman: saying "big files are okay" is not the same as "you should only have big files". When people mean is that having a big file does not provide enough justification to split it. But it is still a signal.