Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A project with a single 11,000-line code file

austinhenley.com

Post reply on HN
Print view View original

121–130 of 346 posts

Re: A project with a single 11,000-line code file

#121

Post by swayvil »

userbinator wrote: post #102

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…

Ah, that takes me back. Commodore 64 freeware games written in Basic.

Ya, you could just go in there and mess with the code all over the place.

Re: A project with a single 11,000-line code file

#122

Post by iaaan »

cookiengineer wrote: post #71

Back in the days at Zynga, there was this ritual that new members of the STG (Shared Tech Group, which developed the game engine stack) had to try to refactor the road logic code. Suffice it to say, it's a 28k LOC file that was so bad, it could even hold up in court as evidence that a South American company stole the code of Zynga's -ville games. We could reproduce each and every single bug and its effects 1:1 in the…

To be fair, the first step towards refactoring is understanding the existing code -- ideally, knowing everywhere it is used, all of its behaviors, and importantly, its history, so that you don't break anything, and so that you don't reintroduce bugs that have already been fixed over the years. Or, in lieu of all that, a robust automated test suite.

This cannot be done with a file containing 28k lines of code. That is an insurmountable task. They may as well have been asked to start from scratch and build a new engine.

I'm curious what the purpose of this ritual was. Was it just hazing, or was the thought that someone might actually be able to accomplish this?

Re: A project with a single 11,000-line code file

#123

Post by chakkepolja »

activitypea wrote: post #54

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

* Editor support for perfect semantic navigation may not be taken granted

* Compiler support for function-level incremental may not be taken granted

* Editor shows a nice file tree (although you can do that with symbols too)

* Working with git is easier

* Reading code on site like GitHub is easier

Re: A project with a single 11,000-line code file

#124

Post by liversage »

TimTheTinker wrote: post #26
m1ckey wrote: post #18

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.

It's originally written in LISP and this is why it's a single C++ file. However, I believe that it's now being maintained in its C++ form.

Re: A project with a single 11,000-line code file

#125

Post by tedunangst »

montenegrohugo wrote: post #72
activitypea wrote: post #54

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.

But what's the difference between file1.c ... file50.c vs cat file*.c > onefile.c?

Re: A project with a single 11,000-line code file

#126

Post by lucb1e »

thedanbob wrote: post #8

I once inherited a mission-critical PHP project which had no version control, no tests, and no development environment (all edits were made directly on the server). It used a custom framework of the original author’s own devising which made extensive use of global variables and iframes and mostly lived in several enormous PHP files. I was able to clean it up somewhat, but there was one particularly important file tha…

My first thought when reading this description was that step one is to make a local copy, get a development environment setup where you can toy around, see how things fit together. The 'stupid'er the setup (like using plain old files instead of a database), the easier that actually gets (apt install apache2 php; rsync da:files /var/www). Wouldn't that have helped solve this particularly important but untouchable file?

Re: A project with a single 11,000-line code file

#127

Post by Scarblac »

kolinko wrote: post #84
khazhoux wrote: post #80

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…

+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?

Re: A project with a single 11,000-line code file

#128

Post by heavenlyblue »

activitypea wrote: post #54

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

I find IDEs work better with multiple files (i.e. navigation around if you want to have several windows open at the same time), but agree that’s not so well defined.

Re: A project with a single 11,000-line code file

#129

Post by lanstin »

WalterBright wrote: post #103
cookiengineer wrote: post #71

Back in the days at Zynga, there was this ritual that new members of the STG (Shared Tech Group, which developed the game engine stack) had to try to refactor the road logic code. Suffice it to say, it's a 28k LOC file that was so bad, it could even hold up in court as evidence that a South American company stole the code of Zynga's -ville games. We could reproduce each and every single bug and its effects 1:1 in the…

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.

Re: A project with a single 11,000-line code file

#130

Post by teaearlgraycold »

gofreddygo wrote: post #114
userbinator wrote: post #102

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…

Funnily enough, I have recently had great success by reversing the "best practices" on a distributed "micro services" architecture application into a single big Java file. Best practices were the usual suspects DRY, IOC, SQL + NoSQL, separation of concerns, config files over code, composition over inheritance, unexplainable overlapping annotations, dozens of oversimplified components doing their own thing, and some $…

Having the whole project actually in one project is critical. I think some of these “best practices” are actually very useful when applied with caution. But you sometimes need to break the rules. Everything should be optimized for developer convenience. Convenience in deployment. Convenience in debugging. Convenience in refactoring. Only do what HN and FAANG says is “right” when you need to.
Post reply on HN