81–90 of 346 posts
My favorite quote has got to be: "Unit tests aren't meant for you now, it's insurance against a future developer".
Better one good organized file than 100s of folders and subfolders and files and symlinks. I have worked on projects where even after 2 years I didn't grasp the folder structure and just used search to locate files.
People love to complain about things that are simple, fast, and easy to complain about, without regard to whether the complaint is insightful or useful. It's sort of the dark twin of bikeshedding. If you divide the single 11k-line file into a thousand 11-line files, it may become objectively much harder to understand, but it'll also receive much less flak, guaranteed. I suspect this is also why Architecture Astronaut…
That's me when I use languages that don't support circular imports. Can't have circular imports if everything is in the same file. Taps head.
So afraid to write bad, spaghetti code, I ended up writing no code at all. This thread made me realize that it's better to have a working profitable project with bad code, than a perfect unfinished project, with meticulously chosen design patterns. Afraid of being judged for bad code, I could not start until I had the right architecture. I'm glad I read this. This is developers therapy.
I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking s…
I had a lot of trouble trying to explain this to juniors.
The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse than into a code that would be 10k lines in one file, but with a flat structure and less interdependency.
I don't get the obsession with file length. What's the benefit of having 100 files with one 50-line function per file, over having a 5000 file with 100 functions? Obviously not counting extreme cases where the file size would break some editors' buffers
Try debugging a single 10k loc file versus fifty small modules where each takes care of a distinct part of the logic.
I prefer many short files and folders structured hierarchically and grouped semantically. I have no proof this is better so I would probably just leave it to a vote with the team.
In the end I think they is how a lot of this should be viewed until we get proper research. How do you WANT to code? TDD? No tests? One giant file? It should be a team and executive decision.
If you don't like the style on your team, and nobody wants to change it, move on or adapt.
Technical debt is like a superfund site. It renders the real estate worthless and poisons the rest of the company.
It does matter. My current gig is hemorrhaging money because we can't keep devs even though the pay and benefits are great. We cannot execute on mission critical initiatives.
We cannot adapt our product to meet the needs of the market in an agile way.
This is due to people saying "a working product is more important blah blah.." for years. I would argue there is a balance to strike and you can do both with a good team and realistic planning. But there is always the nay-sayer who is willing to step in and say whatever product wants to hear.
It is so bad we cannot train people to use the software anymore. It is too poor quality and were can't on-board them before they decide to go elsewhere.
Everyone who knew anything has left and there is too much of it. So the remaining devs get overwhelmed, they leave... It is a vicious cycle.
The funny thing is the money machine works, but it is so frustrating to see all of the extra money we could be making and having to leave it on the table.
IMO, organizing source code in files seems archaic. E.g. tracing the history of a function moved across files can be tedious even with the best tools. I’d like to see more discussion around different types of source storage abstraction.
There are benefits of large source files... When compiling hundreds of thousands of files (like Office), the overhead of spawning a compiler process, re-parsing or deserializing headers, and orchestrating the build is non-trivial. Splitting large files into smaller ones could add hours of just overhead to the full build time.
The .NET runtime GC is a 47k C++ file. https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/g...
Someone please tell me this is transpiled from a separate project.
All of which is to say, by all means argue about whether colossal files are acceptable software engineering, sometimes that fight takes a back seat to "a double-digit percentage of the company's CPU and memory are wasted on parsing and loading this file in literally every new process".
I don't get the obsession with file length. What's the benefit of having 100 files with one 50-line function per file, over having a 5000 file with 100 functions? Obviously not counting extreme cases where the file size would break some editors' buffers
If it were a huge, single file, with very understandable modularity within that file, likely nobody would've bothered to write a blog post about it :-)