131–140 of 346 posts
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.
Is that the same for all languages?
A seasoned programmer should have no problem navigating a multi-million-line codebase, that's just routine.
There isn't anything that special about a 10k file.
I remember many years ago coming across a reimplementation of the server side for a popular MMORPG of the time, reverse-engineered from the client (which was Flash) by what was likely a teenager --- it was over 100k lines in a single file, written in Visual Basic. Global variables everywhere, short names, and not even indentation. All the account data was stored in flat files, there was no actual DB. No "best practic…
You can get away with a lot on a single developer project and best practices aren’t in place solely to make code functional. That application would likely fall apart if multiple developers of with diverse backgrounds had to maintain it and add new features.
Earlier quoted context omitted.
+1 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…
Less interdepency is absolutely the key to everything. But... isn't the easiest way to show that there is little interdepency to put them in separate files that don't import from each other?
Earlier quoted context omitted.
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 don’t think this dichotomy is helpful. I’m presently working at a startup that’s trying to dig itself out of a hole created by the first CTO, who in doing things “quickly” created an MVP so buggy, inefficient, crash-prone, and unmaintainable that we can’t retain customers or engineers. As always, there’s a balance to be struck, and ways to operate quickly that don’t sacrifice quality too much.
Earlier quoted context omitted.
It's impossible to refactor spaghetti code without a comprehensive test suite. But you can do it with a test suite - I've done it with large code bases.
You sometimes can. Maybe for any legacy code base someone could, but I have tried and failed on more than one occasion. Some people’s thought process is just perversely different to mine and I keep feeling, oh, this is the layer where that happens, but no every time I have an aha moment I am disillusioned.
Learned repeatedly from painful experience.
The existence of large files is mostly just a style issue.
Text editors with different or lets say more semantic interfaces to the code would not care about file size.
You could then happily have 1M loc in a single file.
You would care about it as much as you care about how the code was laid out on sectors and pages on your HDD.
I remember many years ago coming across a reimplementation of the server side for a popular MMORPG of the time, reverse-engineered from the client (which was Flash) by what was likely a teenager --- it was over 100k lines in a single file, written in Visual Basic. Global variables everywhere, short names, and not even indentation. All the account data was stored in flat files, there was no actual DB. No "best practic…
You can get away with a lot on a single developer project and best practices aren’t in place solely to make code functional. That application would likely fall apart if multiple developers of with diverse backgrounds had to maintain it and add new features.
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.
If you split it, it's crucial that you're splitting the logic in the right way (if the modules are too small, they'll just waste your time) and that you're making sure references can be easily traced (eg. if you have modules with some DI system which prevents references from being recognised, as it happens frequently in certain node.js enterprise applications).