💾 Archived View for bbs.geminispace.org › u › clseibold › 5605 captured on 2023-11-04 at 13:23:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
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 · 6 weeks 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 · 6 weeks 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 · 5 weeks 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.
2023-09-28 · 5 weeks ago
It's fun to read about such in a state of retirement from the craft.
I still write an occasional Lua scripts, which occasionally burgeon into something conducive to agonizing over abstraction-motivated structuring. But then I remember that enough time away from such undermines its (alleged) benefits, i.e. down the road I'll be equally mystified whether it be monolithic or separate-file-structured.
Something similar happens to me with comments, because invariably whatever I write won't include context I'm not consciously aware of at time of writing, such that months/years later detailed commenting is no less questionably useful than whatever structuring/non-structuring I may have agonized over.
Also (brace yourself to wince..), I wound up concluding that empty lines in the context of brace/indentation consistency were less helpful to my apprehending what I'd done in the future than being able to see more lines at once without them. Sure, one can also de-magnify to see more, but aging also tends to degrade vision, such that smaller text eventually becomes useless.
Try to take the following as an attempt at humor. I'm going to refactor:
"life sucks and then you die"
to:
"coding sucks and then you pick up a guitar"
:-)
2023-10-29 · 6 days ago