An extreme example - 'function A' receives a value, processes it, and returns another value, only issue is, that the value returned is slightly incorrect, so the softy writes another function to overcome this issue - the incorrect value is then passed to 'function B' which returns it's value, which is unfortunately also incorrect, not perturbed, the softy writes another function to deal with this... Somewhere around about 'function K', the correct value is returned. And everyone is (blissfully see more unaware, but) happy - except for the next engineer to look at the job! (which in this case was me - a true example)

I am still amazed that in D7 there are includes, within included files that are themselves included in other files, that are themselves called within class files - jeesh (sound familiar - lol - bit's tacked on to other bits tacked on to other bits...).

Whatever the reason, it's not good code practice, and as Code Satori mentions - "focus development efforts on a new, fresh framework that doesn't bear the weight of old and outdated code." seems like sound advice. You've obviously started to do this with D7, but IMO the philosophy behind the code is still flawed and has some way to go.

With a decent framework / standard it's easy as you instinctively know how something should function - the framework sets the rules for how things should be written - especially in regards to things like reusable code and scope.

D8 (Trident) promises to be better in this regards, (is being described as a framework) - but if the realization of what a true framework really is / consists of, has only come into play with D7, then I'm afraid that D8 will have all of the same inherent issues as we have seen with D6 and D7, as it has already been in development for a lot longer.

...just some food to provoke conversation. ;)

/DM