Hacker News Reader

Comment by 0xbadcafebee | Hacker News Reader

Readability doesn't matter much when you have 10,000+ lines of code. You aren't going to read all that code, and new code introduced by other people continuously isn't something you can keep track of, so even if you understand one tiny bit of code, you won't know about the rest. You need a system of code management (documentation, diagram, IDE, tests, etc), to explain in a human-friendly way what the hell is going on. Small chunks of code will be readable enough, and the code management systems will help you understand how it relates to other code.

View on HN

> Readability doesn't matter much when you have 10,000+ lines of code. You aren't going to read all that code (...)

You got it entirely backwards. Readability becomes far more important with the size of your project.

When you get a bug report of a feature request, you need to dive into the code and update the relevant bits. With big projects, odds are you will need to change bits of the code you never knew they existed. The only way that's possible is if the code is clear and it's easy to sift through, understand, and follow.

> You need a system of code management (documentation, diagram, IDE, tests, etc), to explain in a human-friendly way what the hell is going on.

That system of code management is the code itself. Any IDE supports searching for references, jump to definitions, see inheritance chains, etc. Readable code is code that is easy to navigate and whose changes are obvious.

> Readability doesn't matter much when you have 10,000+ lines of code. You aren't going to read all that code,

As someone who has read 10,000+ lines in order to track down surprising behavior in other people's code, I can say without a doubt that readability still matters at that scale.

Code management systems can sometimes be helpful, but they are no substitute.

> Small chunks of code will be readable enough

Ravioli code is a real problem though. Saying small chunks are readable is not enough. The blast radius of a five byte change can be fifteen code paths and five million requests per hour.

10KLoC is a very small app. Ours isn't that big and it's 140KLoC and I have read almost all of it.

To be fair, not all lines of code are equal. A project with a state machine, commands, strategy patterns, etc requires an awful lot of repetitive boilerplate.

A number-crunching app or a data processing pipeline packed with spaghetti business logic is far harder ti read.

And that is why KLoC is a very piss poor metric.

>A project with a state machine, commands, strategy patterns, etc requires an awful lot of repetitive boilerplate.

Yeah, good thing we're not a java shop...

Even if you’re not going to read 10.000+ lines, if the few you read are easy to understand you’re still going to have a much better time maintaining the codebase.

> You need a system of code management (documentation, diagram, IDE, tests, etc), to explain in a human-friendly way what the hell is going on

I think this is where AI could be helpful in explaining and inspecting large codebases, as an assist to a developer.

Maybe but hallucinations become a real problem here. Even with publicly available API's that are just slightly off the beaten path, I've gotten full-on hallucinations that have derailed me and wasted time.

> I think this is where AI could be helpful in explaining and inspecting large codebases, as an assist to a developer.

That's a great point. Everyone lauds the benefits of chatgpt/copilot in generating new code, but I'm starting to learn that the places they might shine is onboarding onto projects and preliminary code reviews. What LlMs excel at is context, and they should excel in activities where context-awareness is key.

Reply on news.ycombinator.com