A Sane Directory Structure for Software Projects
8 points by FedericoSchonborn
8 points by FedericoSchonborn
I used to spread my code out across too many files and folders so now I think it's generally a bad idea that doesn't improve clarity. It really depends on the project scope and team size, but I think there should be a bias towards more flat structures. It's hard to speak on the topic universally though. The question that I ask myself is: is this making the project easier to understand or am I just doing a meaningless ritual?
I spent my career writing code primarily in Java, Scala, Ruby, Python, and some Rust. My standards on what unit of code belongs in what file is all over the place and I just want a tool to tell me what to do if the language itself doesn't require it, like Java does.
For OOP languages, I like the idea of one class per file because it is so strict. It completely removes arguments about what belongs where. My several years in the Scala ecosystem relaxed that feeling— group things logically into modules but the classes are still individually addressable— and Python complicated it even more. Heck, the python code that I'm maintaining right now is such a mix that it simply has no real standard. I think a recent version of Rubocop just made one class per file the default for Ruby, and now I've got some old Ruby code bases in which I had to disable that.
I'm getting back into Rust after a few years away and just starting to relearn how people are organizing their code these days.
Yeah, in my experience only people who only ever worked with one language have strong opinions on this (or should). If you use 2-3 per week it all falls back to "whatever is standardized in this ecosystem and is not obviously stupid" wins for me.