Comment by samsquire | Hacker News Reader

Comment by samsquire | Hacker News Reader

Parent Full thread

At one point in time I used OpenGrok to try understand large projects.

Without documentation I find large projects difficult to understand. There's literally too many global symbols and I cannot see the forest for the trees.

What's the model of this program? What are the core principles that the author is using? Do I really need to read every file to understand what is going on?

With Leetcode style programs there's one file with everything in it and I can usually find the entry point. The problem is well defined.

I can see the moving parts in a Leetcode style problem. The looping, the data structure creation and control flow, arrays and recursion.

Large mature codebases such as Java projects have thousands to millions of small files and packages it can be difficult to see how things fit together, every file seems to be 10-20 lines long.

I like C projects as they have lots of code in one file. Everything I need to understand a module is in one file and I can use vim folding.

I’ve been programming for nearly 30 years and I feel the same way. 1000loc+ files are increasingly common in my code bases. I find it really hard to read code with lots of tiny files that individually don’t do anything. It’s like the programmer is embarrassed by their code so they’re making me search for the core logic.

Splitting code into multiple files really only makes sense to me when there’s a clear division of responsibilities. That can mean a lot of things - like client / server, utility methods / core algorithm or class A / class B. But plenty of complex data structures are much easier to read and understand all at once. For example, I have a rust rope library which implements a skip list of gap buffers. The skip list is one (big) file. The gap buffer is another file. Easy.

Same. Well, 1000 is an outlier but 300-600 feels right. I sometimes feel bad for doing it, because it's not what some other people might consider good code to look like. I occasionally have to do code review or help fix a bug in a the other kind of codebase and even the devs often don't seem to understand how those thousand 15-line files all fit together.

> Without documentation I find large projects difficult to understand. There's literally too many global symbols and I cannot see the forest for the trees.

Good abstractions let you see the shape if the forest.

Most "good code" or "simple code" is an inedible potluck of "simplest solution for the problem at the time" with some documentation.

Actual good code has intention revealing abstractions that communicate the essence of the problem and problem domain.

back when i inherited a legacy C codebase i found https://www.jgrasp.org/ pretty useful to explore large files.

I could see this working with vim folding. That's an interesting approach. I never really used folding in IDEs.

Reply on news.ycombinator.com