As soon as I stopped trying to write textbook OOP stuff, this stopped occurring to me. That was years ago.
I’m not saying I write perfect code, no. But when I read bad stuff I wrote, I can understand and it and think of ideas about how to improve it if that becomes necessary.
On top of writing more functional-style code, the way I achieved this was:
Absolutely no inheritance whatsoever. Composition + interfaces work wonders for what I do.
Minimal mutable state. This pays dividends when debugging.
Ditto for type-system-encoded nullability markers (ie. ? in C#, std::optional in C++…)
I avoid writing code just-in-case something happens. If I haven’t run it manually or via unit tests, it goes to the garbage bin (not an absolute, just a guiding principle). There’s a chance that code isn’t even correct to begin with and you’ll have to throw it away should you ever need it.
Low indirection. I don’t want to jump through 10 functions to see what something is doing, and nobody else does either.
As soon as I stopped trying to write textbook OOP stuff, this stopped occurring to me. That was years ago.
I’m not saying I write perfect code, no. But when I read bad stuff I wrote, I can understand and it and think of ideas about how to improve it if that becomes necessary.
On top of writing more functional-style code, the way I achieved this was:
?in C#,std::optionalin C++…)