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

191–200 of 346 posts

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

#191

Post by magpi3 »

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

Eventually a single file won't scale. Maybe not in the lifetime of your project, but you never know. If a day comes and you have a 500,000+ line file that must be split into separate files, that could be a nightmare. Why not just follow best practices from the beginning and separate your programming logic into different logical/related units?

Similarly having the discipline to separate your programming logic into different files will force you to think about the architecture(or lack thereof) of your program. This is a good thing. The Java "one file for one class" model is overkill IMO, but it does force programmers to discipline themselves by thinking in terms of namespaces/classes when they write code, which for beginners at least is not a terrible thing.

Obviously version control is another reason. Hard to get work done if everyone is working on the same file.

It also will make it easier for someone else to grok your program. When I git clone someone else's large project, I start trying to understand the project by writing down what each folder and file is designed to do before I go any further. I suppose if everything was in one file I would just have to do the same for functions, but what if there were thousands of them? Imagine if a large program like WordPress, Doom, the Linux Kernel etc was a single file?

TLDR: For small one person projects, no big deal. Otherwise, it's just a bad/unscalable practice.

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

#192

Post by gridspy »

wsc981 wrote: post #181
gridspy wrote: post #141

Earlier quoted context omitted.

> The worst type is when someone had the time to overarchitect and overengineer things. I concur. Refactoring should be as much about removing unneeded abstraction and features as it is about adding same. > there is little incentive or bonuses for improving the situation. Yeah, I just can't seem to believe this in my soul. I just want to fix ugly code and can't stop myself. I get huge satisfaction from speeding up, t…

I try to sneak in refactoring with other tasks.

I find the best method is:

1. Figure out what needs doing and what code you need to use

2. Refactor the code you're using until the new code or change is easy

3. Make the change

4. Tidy and document.

Repeat

I often also document during step 1, while I am trying to understand code and realise that comments are missing.

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

#193

Post by tambeb »

One can develop* what serves as the edifice[1] of a $1B hedge fund that handles signals, orders, trades, positions, and p&l, among other things, using a system not unlike this one.[2]

[1] Merriam Webster definition of edifice: a large abstract structure

[2] Source: Me

* Or inherit and maintain

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

#194

Post by sedatk »

This was common with Delphi/Pascal because units were designated per file, and nobody wanted to type hundreds of "uses" statements to import every one of those. So, people leaned towards keeping code in as few files as possible. For example, TurboVision had units named "Objects", "Views". I'm sure they were thousands of lines long.

It was possible to use include files to split up a single unit, but that wasn't used much either because lack of cross-file navigation features in IDEs of the era made it really difficult to manage many files.

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

#196

Post by gridspy »

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…

Man, now I want to test myself against your road logic code. Sounds like a worthy challenge.

Always tricky though when the hacks have both undefined features AND bugs.

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

#197

Post by JoeAltmaier »

I've refactored monolithic code several times in my career. It starts with a thorough going-over, making notes, identifying the state machines and drawing what was handled and what was not.

Then, reimplement as a simple state machine but this time, fill in all the transitions (event+state => new state + action)

One was an Infiniband code base from the vendor - a 'computer scientist' had written several layers to do what one or two could accomplish. Another, the Windows CE DHCP client (went from seconds to choose an address to milliseconds). Then there was an HDLC modem protocol - I got done, that was sped up a multiple and no longer crashed.

I can't understand them by just reading. I had to make a road-map of all the states, events, actions and interfaces. Design a new code. Then make sure every function of the 'old' code was represented in the new code - line by line. So nothing got dropped.

Satisfying. But more like turning the crank and making sausages than design or architecture.

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

#198

Post by georgiecasey »

Surprised nobody's mentioned the Telegram Android app yet. Their ChatActivity.java is 27, 720 lines! https://raw.githubusercontent.com/DrKLO/Telegram/master/TMes...

Thing is, there's a great knowledge of the Android OS in there and the app works great when I use it. I think the OP blog post is correct 'Users don't care about the technologies or code.'

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

#199

Post by exdsq »

sillysaurusx wrote: post #179
exdsq wrote: post #164

Earlier quoted context omitted.

The only readability issue I have with that is the functions expected arguments. Add some types and I’d be very happy to work on it. I believe Facebook uses a single directory of files now as best practice? With the file names including namespaces. That was an HN comment from ages ago so could be wrong or misinterpreted.

pg's new lisp, Bel, has something close to typed arguments: (def add1 (x|int) (+ x 1)) http://www.paulgraham.com/bel.html I've been implementing it for a couple years now, though not seriously till the past couple months. There are some interesting (and overlooked) ideas in Bel. Bel is sort of the limit case of generality. For example, you might expect the "type" above to be a separate kind of object, the way that ty…

It's nice to have invariants - I believe I've seen them in Rackets contracts but I'm a little away from that stuff in my Lisp journey :)

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

#200

Post by hulahoof »

iaaan wrote: post #122
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…

I would expect people new to the code base would look at this gigantuan file and ask why it hasn’t been refactored, and this probably was seen as an opportunity to familiarise new hires with the code base as well as get them on the same level as to the effort involved in a refactor.

I agree with you, a rewrite is probably how they should have tackled this one.

Post reply on HN