Live data from Hacker News

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

austinhenley.com

71–80 of 346 posts

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

#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 their games, with all the crashing scenarios that were easy to reproduce, hard to debug, and almost impossible to fix.

Once you dig into the hole of depth sorting and being smart by "just slicing" everything into squared ground tiles on the fly, there's no way out of that spaghetti code anymore.

Fun times, was always a joy seeing people give up to a single code file. The first step to enlightenment was always resignation :)

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

#72

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.

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

#73

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.

[deleted]

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

#75
post #47

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.

You sound like you should read this: [removed] apparently jwz decided not to be linked from here :/ there's an archive.org link below.

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

For future reference, a non-archive, non-jwz.org link. Straight from the source as that's the author's own site.

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

#76
i used to work on 40-50k line files with one function and a bunch of gotos in perl, in a multi billion dollar company

its fine

you just binary search your way into it, put print "AAAA" in the middle, see if its printed, then put it in the half of the half and try agian.

emacs couldnt even find the bracket ending of the if condition (not the block, the condition..), have you ever seen if conditions(again, not the block) that spans your whole screen?

its not as bad as you think, it made me realize we take code very seriously, but its actually ok, 10k line file 100k line file, whatever.. its all the same

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

#77
post #47

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.

You sound like you should read this: [removed] apparently jwz decided not to be linked from here :/ there's an archive.org link below.

Put it like this: www.jwz.org/doc/worse-is-better.html

Then just copy & paste it.

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

#78

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…

> dark twin of bikeshedding

is it different from regular bikeshedding? or are you saying that the dark twin is the evolutionary process of eg. architecture gaining complexity until it becomes difficult to criticize..

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

#79
post #62

It really speaks to the state of software engineering when there are ample comments here defending this practice. This is virtually indefensible in my book, as it screams technical debt and strongly suggests that there are much deeper issues hiding in that codebase. Personally I would not be willing to work on it without first addressing those issues.

It speaks to the state of software engineering that people are complaining about file length, instead of something meaningful like cyclomatic complexity. A 10k single line program can be easier to understand and better organized than an overly abstracted mess strewn across multiple files, but which checks all the "best practice" checkboxes.

Do you think the people who wrote this were measuring cyclomatic complexity? Obviously you can have >10k LOC file that is well-maintained and useful.. but there's ample evidence in the post that this was _not_ one of those, but a machine held together by duct tape, spit, and hope.

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

#80

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 shortcuts. But in the end, even their code doesn't have the strongest tests, doesn't generalize for all the known use cases, etc. Team B never gets users or gains momentum, and their code+architecture was probably no better than Team A -- they just took 3x the time to get there.

Post reply on HN