Nathan Nobbe wrote:
i understand designing for simplicity is key, however, things can only be kept so simple beyond reason. the more something does, the more complex it is; period. -nathan
Nice touch, but what I'm most afraid of is abstraction layers. It is good to know what to abstract, but also how it is abstracted and where it came from.
Sometimes, abstraction makes it so unbelievable complex, just because of the sake of abstraction (or over-engineering). Maybe it's just me, but I like things clean and simple. I can't grasp oversight easily. Especially when it's someone else's code.
I do acknowledge the need (or purpose) of OOP, but sometimes you can make it more clean and simple by getting rid of the clutter. If you don't know anymore where the code is that you need to edit, you have to read the code over and over again (parsing it in your head to something that makes sense). If you have to do this 10, 20 or even 50 times a day my head explodes.
I have to deal with spaghetti code from some old code-base every day, it frustrates me because I can't get inside the head of the programmer who wrote this trash. Nice patterns, nice classes (not so OOP), no documentation. It takes to much memory, to much included files (125+), to many templates, sometimes a 1000+ queries per page (mad!).
No. Give me procedural code please. I can read that from top to bottom, it sticks on 1 flow of the processing. Downside is having some code multiple times all over the place (hence an argument for OOP). But that saves me time and a huge headache every day. I like it to maintain it that way. And maybe the programmer after me has to clean it up too. But refactoring procedural code is way easier that refactoring OOP code is my opinion.
-- Aschwin Wesselius <social> What you would like to be done to you, do that to the other.... </social> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
