[gkaemmer]

At the same time, I find that it's often hard to comprehend projects that are broken into too many little files. There's normally no guide on what pieces are where, so you don't know which order to read things. Makes it a little tougher to dive in. I just want to find the file that has the "meat", and I don't mind if that file is 1000+ lines long, especially if the code itself makes sense and is clear.

[erikpukinskis]

Agree.

But I’m advocating something much stronger than that: breaking them down into small modules each with a published interface.

You can see what all any given module depends on by looking at one set of imports at the top of one file.

Each of those has a github repo and a README, so it’s easy to find out what they do...

But most importantly, the architecture of such a library will be wholly different than what it would have been if developed as a monorepo.

My point is not really that this structure of code is ergonomic. It’s that forcing yourself to do things this way forces you to clarify the purpose of modules. And to discover interfaces which are truly orthogonal.

And that makes the code easier to understand.

[de_watcher]

> the file that has the "meat", and I don't mind if that file is 1000+ lines long

I prefer "meat" separated. And having clear boundaries. 1k+ lines is a bad sign.

Even if it's well-structured, why force your idea of how much I have to scroll?

And why making git diff overviews less useful? (glance over filenames)

[et1337]

Completely agree. This is a common problem with object-oriented code bases. You've got hundreds of 20 line source files and the only way to decipher them is to trace the execution all the way from main() down to the last util class.