💾 Archived View for bbs.geminispace.org › u › clseibold › 5650 captured on 2023-09-28 at 16:55:56. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "I was recently reading other people's code, and I'm..."
@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.
2023-09-27 · 1 day ago
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.
14 hours ago
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)...