I suppose this part is just a rant, but if I see one more piece of undocumented, poorly spaced, procedural lump of PHP code, I’m going to scream. I realize that much of the PHP code out there was written for free by people who were writing code just to “get the job done”…I understand that. Unfortunatley, when that code is published, others rely on that same code for thier job. Sure it’s free and you have a disclaimer and…whatever. There are 1000 excuses, but only one cause: Poor software engineering practices.
Perhaps due to the ubiquity of PHP among web developers, actual engineering skills may be…well…lacking. I see this a lot with many of the Drupal modules I end up having to fix to get MY job done, and I think it’s time that if you are going to call yourself a web developer, you need to flex some software engineering skills!
Document Your Code - No one likes to dig through code all day and guess what they are looking at. When I say document, I dont mean write a formal SRS or SDD. I mean document EACH class, function, and major block of code in a consistent manner. Take a look at phpDocumentor. This package is a lot like JavaDoc, Doxygen…It makes you adhear to a certian standard, and in return you get a really nice API reference page/site.
Adopt a Coding Standard/Style – A good place to start for this is the GNU Coding Standards site. While each project, group, or company will likely have thier own standards, at least this is a start.
Name Things Appropriatley - This has become a huge pet-peave of mine lately: A php page with variables $a-$z. These variables mean NOTHING! For example, if I say pass in the $a variable to a function, what does that mean? How about when I call it the $StudentsArray? THAT tells you something!
Start Using OOP - Object Oriented Programming (OOP) is essential in creating readable and sustainable code. While I may take some heat on this, no one can deny that PROPERLY ENGINEERED OOP code is generally much cleaner, more reusable, and much more maintainable than the comparable procedural lines.
Break Your Code Up - As the author of a number of one-page scripts in the past, I can tell you that this style of coding is not the way to go. Try reading – nonetheless fixing – a huge monolithic heap of code. A great start is to simply begin grouping common functions together. Even if they are not reused, it’s MUCH easier to unit test code when it’s in small pieces.
It really comes down to this…If you’re going to publish code under the guise of being completely usable, be proud of what you publish! Take the time to make it right. Sure, when you’re working for free, who has the time to make things 100%? At least make the code you have readable enough so someone else can try!