You did the right thing. OOP was invented by people who were worried about their job security, to obstruct others from understanding their code.
ihan normi koodi työ ukko
You did the right thing. OOP was invented by people who were worried about their job security, to obstruct others from understanding their code.
In particular business logic that’s not obvious should be documented in comments.
// Typically 1 = 1, but on March accounting wants that 1 = 2. This function makes that mapping.
Just remember to mark all the things you’d like to make better but can’t be arsed to at the moment with numerous TODOs.
Hi colleague! So I found a comment in the code from 3 years ago by you saying you should “improve this”. Is it planned for the next sprint?
Few of the good ones I’ve spotted:
(complicated business logic in messy code) // TODO: check
(…) // TODO: think about better naming
(…) // TODO: This is obviously shit and needs to be changed.
(…) // TODO: THIS IS NOT USED ANYWHERE CONSIDER REMOVING ALTOGETHER (comment made 3 years ago)
Do I understand this correctly, that the first astronaut’s realization is that all data structures are graphs?
If yes, that doesn’t make much sense. How is an array a graph?
That freedom becomes misery on the instant you have to start maintain the code from some other free spirit, whose style is totally different from yours.
Well, bad code is bad code regardless of the paradigm. I’ve just had bad experiences rewriting some horrible OOP codebases and opted out to use as much functional style as C# allowed me to.
The main problem, as I see it, is that OOP encourages unnecessary abstractions and inheritance. These should be used as little as possible, because they typically increase complexity and make code harder to read and untangle. As an example, I’ve seen people define interfaces that don’t essentially define anything.
Another problem is that OOP encourages mutable member variables. It’s very annoying to try to understand code where class C inherits from class B that inherits from class C. Good luck debugging when the methods of C modify a variable declared in A in subtle ways.
As an idea OOP is very appealing. When I was younger, I would be thrilled to start designing a class hierarchy and interfaces when encountering a new programming challenge. Now I just try to think how to make things as simple and modular as possible.
Edit: of course bad functional code is also bad code. It’s also very annoying to try to understand code where functions pass badly named functions around as parameters and use 10 function compositions in a sequence.