I’m working on a fairly large PHP project written in a procedural style (it was written before PHP 5), and I can’t help but feel that some of the things I’m doing are a little “hackish.” A modification somewhere else can easily break the application. All the design patterns and best practices I’ve seen seem to only apply to OOP. I could start writing some of my code using PHP 5’s OOP features, but I’m not sure if all the other developers are familiar enough with OOP.
Is it just the nature of procedural programming to seem “hackish” to people more familiar with OOP? Are there “best practices” books that deal with how to keep large procedural applications maintainable and make the introduction of new bugs less likely?
I know I could apply OOP design principles/patterns in a procedural way, but if I was going to do that, I might as well just use PHP’s OOP features. Maybe I just don’t have a good enough understanding of the procedural paradigm?
Procedural programming, especially in PHP, doesn’t have a concrete notion of “encapsulation” — everything’s available, it’s just not your job to modify it, so you don’t. To those who don’t know anything but OOP, or were taught that procedural code is BAAAAAAD, yes, it can look hackish and wrong. But people have been doing it for a LONG time, and it does work.
Now, it’s just as likely that you’ve found some of the ACTUALLY bad procedural code. There’s as much of it as there is bad OOP code.
Basic practices for procedural code aren’t a whole lot different than for OOP — avoid globals if possible, group related functions together and try to keep them short. There aren’t really “patterns”, per se, as procedural programming predates the patterns movement by a few decades. But clean procedural code need not be as ugly as the OOP zealots would have you believe.