💾 Archived View for bbs.geminispace.org › u › clseibold › 5605 captured on 2023-09-28 at 15:54:50. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I was recently reading other people's code, and I'm reminded why I don't usually ever do this - I hate reading other people's code. I program very differently than a lot of other people.
I don't make tons of 5-line files, but it has become common to make tons of 5-line files, and it just makes your code extremely confusing to navigate.
I don't do classes. OOP makes you abstract more than you need to, is extremely confusing to navigate (it almost requires that you make tons of 5-line files, lol), and ends up making you focus more on abstracting things into boxes than making sure your code is understandable or easily usable.
2023-09-26 · 2 days ago · 👍 sirwilburthefirst
I could not agree more. I tried to plead my case on this issue at my last job and was basically told that I was wrong and it is "so much clearer this way". Which is just false.
+1 to this, the two main codebases at work have these and giant god files where everything comes together; thankfully we are working on refactoring this code to be more structured
2023-09-27 · 2 days ago
I found that denser code requires more "working memory" from a developer both to keep track of where a block of code is and the impact of a change. If you can keep that in your head, great. Most developers I work with struggle with more than 2 kLOC in a single file and about 20 kLOC in general.
With smaller files and developers new to the code base, I found it was easier to say "you can ignore this file unless..." that comes with Single Responsibility Principle.
But that isn't for everyone. I used to hack on lout, a LaTeX like parser. Ten files of dense code labeled with only a single letter (k.c, h.c, etc). For the single developer who worked on it. it was great. For someone coming in? It was much harder.
That isn't to say that non-OOP code is automatically more complex. It has a lot of extra cruft to it, and that can end up in a different type of noise; the "you are in a twisty tunnel" of Adventure.
But, I do favor smaller files that separate concerns. It is easier to only focus on a single concept or responsibility.
2023-09-27 · 1 day ago
@dmoonfire I don't agree that "denser" code requires more working memory. It requires less, because you don't have to remember where everything is in which files and directories, unlike complicated directory structures. Nobody is saying you have to memorize everything in a file. My point is you don't have to go to several different files remembering where everything is located, to read the code.
When you take SIngle Responsibility Principle as gospel, imho, this is how bad code gets written, because people end up shoehorning things and over-abstracting to the point they are more focused on creating a categorization system.
How a function gets written depends on its purpose. Some functions need to be big.
If we are solely talking about single-letter filenames or single-letter variables/functions, then of course that is unreadable bad code. But that's not what I'm talking about, so I don't get why you went to that for non-oop code. That's not how non-oop code is written, at all.
Non-OOP doesn't have a lot of extra cruft. Classes is extra cruft. Non-OOP languages don't have classes. They have structs and procedures and first-order functions. The biggest problem with some non-oop languages is they are older, but this *no longer applies* - there's plenty of new non-OOP languages that have excellent standard libraries.
Procedural languages are defined by their simplicity in only outlining what is in memory, and that is it. No virtual method tables or other weird stuff. No overriding functions in a class. No inheritance weirdness, etc. You don't need it, because there are simpler means of doing these things that are infinitely more understandable.
Finally, when you take Single Responsibility to extremes, then you are not actually doing single responsibility, you are just dividing the single responsibility up into a million files and functions.
However, nobody said non-OOP languages dont do Single Responsibility. They just don't butcher that single responsibility up into a billion pieces. Look at any standard library in any procedural language and you will see that single responsibilities are divided up neatly into their own files and packages. Golang does this, C does this, Odin does this, the list goes on.
The best practice for readability, imo, is making sure functions are close to where they are used. This means putting it in the same file if the function is only called in that file.
By small files, I mean files that are 30 lines and under, or single-function files, or even single-class files. By normal-sized files, I mean 200 line files, maybe 500 max. Sometimes larger if there's just so much in that single responsibility (which is often the case in standard libraries or complicated functions, like mp3 decoding or whatever).
2k is excessive for many things. Higher than that is even more excessive for most everything, again, unless you're writing code for a very complicated task.
Procedural languages doesn't automatically mean writing 2k or 20k files. That's also not how most non-OOP code is written. I don't know where you are getting this perception.
How a function gets written depends on its purpose. Some functions need to be big.
A thousand times this. I think a common exercise for new programmers is to take some complex, badly written, monolithic code, and to refactor it into smaller functions. And that's a good thing to practice. But I don't think the converse skill is ever taught, that of identifying when a big chunk of logic should stick together.
Sometimes code is big and complex because the requirements are big and complex. Obviously mental overhead can be reduced with some strategic abstraction, but beyond that I much prefer a giant function which mirrors the requirements than the same thing cut up arbitrarily and scattered around.
13 hours ago