5 ms·

> I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far ha

> I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. I genuinely can't tell if you're being serious or not. If you are, do you also like to read books written as one giant chapter? Or entire chapters as one giant paragraph?

samsquire 4y ago
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.
- alphanumeric0 4y ago
  I could see this working with vim folding. That's an interesting approach. I never really used folding in IDEs.
- josephg 4y ago
  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.
  - sanitycheck 4y ago
    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.
- zem 4y ago
  back when i inherited a legacy C codebase i found https://www.jgrasp.org/ https://www.jgrasp.org/ pretty useful to explore large files.
- ParetoOptimal 4y ago
  > 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.
kuroguro 4y ago
I think he is, can second that. Not having to jump around 10 files with multiple classes and remembering where goes what usually means I can understand the code faster. Not sure about literature but for almost any technical matter I prefer learning from the smaller details instead of the big picture - it's often too vague and just doesn't stick in my memory.
kreeben 4y ago
I have trouble with you equating "leetcode style" with "one giant chapter" and also with you equating "enterprise code" with one chapter following another, because when I read enterprise code it's 1. read one line of first chapter, 2. then skip to the last sentence of the middle chapter, 3. then realize the first chapter was actually the penultimate, 4. then read the forth sentence of the first paragraph of the second chapter, bearing in mind what you have learned, 5. then throw your hands up in the air in dispair
- alphanumeric0 4y ago
  Jumping around is the nature of code in general, whether its in a 1000-line file or split up amongst multiple files. For a maintenance programmer, they may already understand how everything works. They aren't following a particular code path, necessarily. Maybe they're working on a new feature and they need to re-familiarize themselves with previous chapters. It that case, it's nice to jump to a file that concerns itself with things grouped together.
  - kreeben 4y ago
    >> things grouped nicely together fixed it for ya :) I'm a maintenance programmer. Even working layers of layers of layers above the actual shit does not make it not stink. >> jumping around ...should be intuitive and joyful, not a disaster to your brain. EDIT: I am a fan, though, of SOC. I guess enterprisey code tries to be that (but fails hard at it).
    - alphanumeric0 4y ago
      Okay, great. You are a maintenance programmer. You have a 1000-line program all in one file. You need to update the e-mail functionality of this program. You aren't following a stack trace or following a particular code path. There are 15 or 16 different e-mail related functions. How do you find the e-mail function you need to update? Do you memorize line numbers? Use regex search? Do you have vim marks setup?
fleddr 4y ago
The book analogy you use isn't very accurate. Even if you merge chapters and paragraphs like that, you still read it sequentially. Just in a less comfortable way. Which is not at all like a modern codebase that is modular, abstracted, etc. If you're new to a codebase, and want to understand one particular feature, you'd likely need to jump back and forth across 10 files. It's not far-fetched to say that makes it difficult to understand.
- tharkun__ 4y ago
  The thing is that if you just need to understand a specific part of something you will need to jump as well even if everything you needed for that one thing is written sequentially in one file. You will want to skip over implentation details of certain things to get the general picture first on a more abstract level. Let's say you have a simple endpoint that takes a list of comma separated inputs, parses them as numbers and spits back a sorted version of that. I don't want to see a version of that, which a compiler might have inlined. Including the implementation of the sorting algorithm. I only want to see a high level of abstraction version of it. Basically just something like (pseudo code in a non existent language) : fun endpoint(input): inputs[] = split(input, ',') numbers[] = parseAsIntegers(inputs) return quicksort(numbers) I can easily understand what this does and what the idea is behind this "algorithm" in 3 lines. If I had the "inlined" version of this I would have to manually identify each of these parts and potentially skip over tens to hundreds of lines. I think this is really a bit about trust. Do you trust that these named functions I am calling do what their name does? Does quicksort actually do a quicksort or has someone implemented bubble sort in there? Of course this is a minimal example and especially quicksort would probavly just be a library but imagine all of these were large complex pieces of our code base. Personally I am an advocate for using functions (methods or whatever your language calls them etc) and naming them properly and then trusting those names by default. I want to spend time making this nice and understandable and abstracted once when writing. Not every time someone reads it. As soon as something does not seem to behave in the way the name suggests I will then and only then go check the actual implementation and for example find out that parseAsIntegers actually also supports floats and quicksort is not actually quicksort but bubblesort and that is why this endpoint was slow etc.
xigoi 4y ago
Reading enterprise code is like reading a book where 99% of the pages don't contain any meaningful information.

samsquire 4y ago

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.

alphanumeric0 4y ago
I could see this working with vim folding. That's an interesting approach. I never really used folding in IDEs.
josephg 4y ago
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.
- sanitycheck 4y ago
  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.
zem 4y ago
back when i inherited a legacy C codebase i found https://www.jgrasp.org/ https://www.jgrasp.org/ pretty useful to explore large files.
ParetoOptimal 4y ago
> 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.

kuroguro 4y ago

I think he is, can second that. Not having to jump around 10 files with multiple classes and remembering where goes what usually means I can understand the code faster. Not sure about literature but for almost any technical matter I prefer learning from the smaller details instead of the big picture - it's often too vague and just doesn't stick in my memory.

kreeben 4y ago

I have trouble with you equating "leetcode style" with "one giant chapter" and also with you equating "enterprise code" with one chapter following another, because when I read enterprise code it's 1. read one line of first chapter, 2. then skip to the last sentence of the middle chapter, 3. then realize the first chapter was actually the penultimate, 4. then read the forth sentence of the first paragraph of the second chapter, bearing in mind what you have learned, 5. then throw your hands up in the air in dispair

alphanumeric0 4y ago
Jumping around is the nature of code in general, whether its in a 1000-line file or split up amongst multiple files. For a maintenance programmer, they may already understand how everything works. They aren't following a particular code path, necessarily. Maybe they're working on a new feature and they need to re-familiarize themselves with previous chapters. It that case, it's nice to jump to a file that concerns itself with things grouped together.
- kreeben 4y ago
  >> things grouped nicely together fixed it for ya :) I'm a maintenance programmer. Even working layers of layers of layers above the actual shit does not make it not stink. >> jumping around ...should be intuitive and joyful, not a disaster to your brain. EDIT: I am a fan, though, of SOC. I guess enterprisey code tries to be that (but fails hard at it).
  - alphanumeric0 4y ago
    Okay, great. You are a maintenance programmer. You have a 1000-line program all in one file. You need to update the e-mail functionality of this program. You aren't following a stack trace or following a particular code path. There are 15 or 16 different e-mail related functions. How do you find the e-mail function you need to update? Do you memorize line numbers? Use regex search? Do you have vim marks setup?

fleddr 4y ago

The book analogy you use isn't very accurate. Even if you merge chapters and paragraphs like that, you still read it sequentially. Just in a less comfortable way. Which is not at all like a modern codebase that is modular, abstracted, etc. If you're new to a codebase, and want to understand one particular feature, you'd likely need to jump back and forth across 10 files. It's not far-fetched to say that makes it difficult to understand.

tharkun__ 4y ago
The thing is that if you just need to understand a specific part of something you will need to jump as well even if everything you needed for that one thing is written sequentially in one file. You will want to skip over implentation details of certain things to get the general picture first on a more abstract level. Let's say you have a simple endpoint that takes a list of comma separated inputs, parses them as numbers and spits back a sorted version of that. I don't want to see a version of that, which a compiler might have inlined. Including the implementation of the sorting algorithm. I only want to see a high level of abstraction version of it. Basically just something like (pseudo code in a non existent language) : fun endpoint(input): inputs[] = split(input, ',') numbers[] = parseAsIntegers(inputs) return quicksort(numbers) I can easily understand what this does and what the idea is behind this "algorithm" in 3 lines. If I had the "inlined" version of this I would have to manually identify each of these parts and potentially skip over tens to hundreds of lines. I think this is really a bit about trust. Do you trust that these named functions I am calling do what their name does? Does quicksort actually do a quicksort or has someone implemented bubble sort in there? Of course this is a minimal example and especially quicksort would probavly just be a library but imagine all of these were large complex pieces of our code base. Personally I am an advocate for using functions (methods or whatever your language calls them etc) and naming them properly and then trusting those names by default. I want to spend time making this nice and understandable and abstracted once when writing. Not every time someone reads it. As soon as something does not seem to behave in the way the name suggests I will then and only then go check the actual implementation and for example find out that parseAsIntegers actually also supports floats and quicksort is not actually quicksort but bubblesort and that is why this endpoint was slow etc.

xigoi 4y ago

Reading enterprise code is like reading a book where 99% of the pages don't contain any meaningful information.