Comment by skydhash
8 hours ago
Now, I tend towards the C idiom of having few files and not a deep structure and away from the one class, one file of Java. Less files to rename when refactoring and less files to open trying to understand an implementation.
One advantage of more smaller files is that merge conflicts become less common. I would guess that at least half of the trivial merge conflicts I see are two unrelated commits which both add some header or other definition at the top of the file, but because both are inserted at line 17, git looks at it and says, “I give up.”
This in itself might not be enough to justify this, but the fewer files will lead to more challenges in a collaborative environment (I’d also note that more small files will speed up incremental compilations since unchanged code is less likely to get recompiled which is one reason why when I do JVM dev, I never really think about compilation time—my IDE can recompile everything quickly in the background without my noticing).
for the first point, such merge commits are so trivial to fix that it’s barely takes time.
You got a point for incremental compilation. But fewer files (done well) is not really a challenge as everything is self contained. It makes it easier to discern orthogonal features as the dependency graph is clearer. With multiple files you find often that similar things are assumed to be identical and used as such. Then it’s a big refactor when trying to split them, especially if they are foundational.