Live data from Hacker News

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

austinhenley.com

241–250 of 346 posts

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

#241

Earlier quoted context omitted.

To develop a comprehensive test suite can sometimes be hard, especially for code that deals with say concurrency, multi threaded code , locks , 2d/3d physics , video , analog , hardware related , procedurally generated or ML (meta-language ) and the other ML (machine learning) etc. A lot of edge cases and race conditions would easily slip through, also a different set of edge cases or race conditions you never consid…

It might sometimes be hard but I have never seen a case where it was impossible (25+ years of experience dealing with undocumented legacy code more often than not).

If work with not easily deterministic code typically but not always ML models like say speech-to-text or Face-Recognition or classification/ recommendation systems or network performance dependent applications like video conferencing that wouldn't be that feasible .

Almost nothing is impossible to test yes, however to know and be able to mock the data for each test case can be extremely hard and at some point not worth the effort to even attempt.

Most I have seen these kind of systems doing is statistical testing with reference benchmark/ sample data, and maybe monitor real world feedback either telemetry or user complaints.

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

#242

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…

I suspect the game was Runescape. My brother used to be a fan of these custom servers.

A likely guess, although RuneScape isn't Flash based (Java & RuneScript).

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

#243

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…

> 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.

A thousand 11-line files? You definitely could not make that guarantee of the people I work with.

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

#244

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.

+100

I'm so afraid of creating programs in languages that don't enforce a structure at all, even though I know how to write everything from scratch make it work.

If it's some framework, then it'll already be structured somewhat.

In the rare event that I do create something with no frameworks, I ensure that there aren't much global variables.

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

#245
post #203
post #122

Earlier quoted context omitted.

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…

It is possible to write tests in a single-file program. You could for example have a -test flag that runs all the tests when the program starts. It's never too late to introduce tests - the next bug you fix, start by writing a test that detects the bug, then fix the bug - and confirm that the bug is fixed by running the test. Then you never have to worry about a bug you already fixed will show up again. And the tests…

> but for API calls and databases, just have the test write to the prod environment, but include rollback/cleanup in the test

I disagree with that. Automated testing should be done on a test database.

Holding a lock for too long could effectively block the entire production. This could happen while debugging through a test (e.g. by hitting a breakpoint or by just stepping line-by-line). Or by simply having a bug in the test causing a "transaction leak" - depending on the tech stack, this could keep the transaction and the associated locks alive until all tests have finished running, not just the one which had the bug.

Or you could commit instead of rollback by mistake.

Or you could simply put unexpected strain on the database, affecting the performance of real users.

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

#246
post #115

Earlier quoted context omitted.

"Flat is better than nested" - The Zen of Python I had an "everything should be broken into a hierarchy!" stage back when I was learning to code, and boy was I off track. In my defense, at the time (and this dates me) OOP was all the rage.

I find OOP spaghetti can be incredibly difficult to navigate, example: Class hierarchies 4 or 5 layers deep, some subclasses overriding the parent, others not. It can be it very difficult to follow what's actually going on. Procedural spaghetti is more manageable, though I once had to update a C app with a 3000 line case statement. Pure madness.

Inheritance hell would be more lasagna code.

Golang does a good job of addressing this one particular problem.

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

#247
post #84

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…

> The most important things is to have code that is easy to refactor Very true. I'll just add that another most important thing is to actually take time to refactor, even when things are busy. I spend maybe 1/3 of my time refactoring, and that feels good.

I like to refactor once I have passing tests and before committing.

Once you know it works take a minute to clean up and make the changes fit your preferred style, extract repeated code into shared methods, comment the tricky bits, etc.

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

#248
post #98

Earlier quoted context omitted.

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.

I'm kind of surprised that you can't find engineers interested in creating a new implementation of an existing application that is actually used by people. I think that might be my dream role.

If your dream job could be in Charleston SC lets chat :)

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

#249

Earlier quoted context omitted.

Be Team C. Team C works like team A. However every time a feature ships, someone who knows that feature well immediately refactors the relevant code to remove the prototype scaffolding. When code becomes static, an expert adds good quality comments. When a bug is found, it is recreated in a regression test prior to being fixed for good.

The sad reality of tech companies is that there is little incentive or bonuses for improving the situation. You won't get a bonus for cleaning up the code or for rewriting rotten code. Hack at the code for 4 years, collect your options and leave the mess to someone else. To be honest, a hacky codebase written fast is not the worst codebase to deal with. The worst type is when someone had the time to overarchitect and…

4 years is a long time to suffer through inscrutable code.

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

#250
post #213

Earlier quoted context omitted.

I'm kind of surprised that you can't find engineers interested in creating a new implementation of an existing application that is actually used by people. I think that might be my dream role.

Business doesn’t want us to stop the bus to change the tires - or spend so much time changing tires that the bus never reaches the destination.

Makes me think of Lightning McQueen losing the first race in Cars because he refuses to pit to change his tires, then blows them out on the last lap.
Post reply on HN