Comment by hot_gril
3 years ago
The way I code now after 10 years: Use one big file. No executable I'm capable of writing on my own is complex enough to need 50 files spread across a 3-layers-deep directory tree. Doesn't matter if it's a backend, a UI, or what. There's no way your React or whatever tutorial example code needs that either. And you don't gain any meaningful organization splitting into files when there are already namespaces, classes, structs, comments, etc. I don't want to waste time reorganizing it, dealing with imports, or jumping around different files while I code.
Oh, there's some custom lib I want to share between executables, like a Postgres client? Fine, it gets its own new file. Maybe I end up with 4 files in the end.
I like simplicity but this sounds pretty awful if you work in a team - file structure can help with the domain design too.
This is sorta how our team does things, and so far it hasn't presented issues. Each service has the vast majority of its real logic in a single file. Worst case, one day this stops working, and someone takes 10 minutes to split things into a separate file.
On the other side, I've seen people spend hours preemptively deciding on a file structure. It often stops making sense a month later, and every code review has a back and forth argument about what to name a new file.
I read it as satire.
Reminds me of a company I used to work at which took a similar approach. We used one file per person policy, each developer had their own file that contained functionality developed by them, named like firstName_lastName.ext - everyone owned their file so we didn't have to worry about merge conflicts.
On the team at my day job, it'd be very bad for each person to strictly "own" their code like that because things get handed off all the time, but in some other situations I can see it making sense.