mikhail panchenko / blog

I’m a little crosseyed from looking at code non-stop for the past few days, so I’ll take a minute to wax philosophical.

I’ve been seeing a few posts here and there that take a very dogmatic approach to things. Take any number of “Considered Harmful” posts, or the “You’re doing it wrong” post. The most recent example is “Comments Considered Harmful” at the PHP In Action blog. All of these posts invariably end up with the author beckpedaling either in the comments or in a subsequent blogpost.

Me, I find all this silly. It’s very obvious that the same set of “rules” won’t apply to every environment. While these sorts of posts tend to “stimulate” discussion, which Dagfinn actually claims as his goal, I definitely think there are better ways to achieve the same thing. I’m sure that a post titled “Making code more readable by modularization” with the exact same content would produce a much healthier, yet equally useful dialog.

The answer lies quite frequently in moderation.

Splitting out complex logic into smaller, well-named function helps, but no amount of modularization will help a developer revisiting my code a year later that performs a 6-fold union to determine what resources a user has permissions for based on multiple relationship paths. That shit is confusing even to me. Nor will an ORM be able to do this work for me, at least not efficiently.

Using a framework is nice, but if you’re in an environment where the stack has been hacked up and customized, they frequently won’t work or will produce unexpected behavior. Naturally, there’s always the performance issue. There is nothing wrong with writing your own “framework,” whatever that may mean to you, that suits your own specific needs.

A careful examination of a problem tends to lead to a good solution. There are very few right solutions.

Here’s my list of “You’re doing it wrong if:”

• You don’t take the time to fully understand the problem you’re trying to solve
• You don’t document the thought process in a centralized, well known location
• You don’t discuss the problem with anybody
• You discuss the problem with EVERYBODY, including people with their own agendas that have no interest in that particular problem
• You don’t consider how future changes will affect your work
• You aren’t aware of already-existing solutions  (I see SO much crappy code being written while there is a well supported solution already available, sometimes from within the company)
• You refuse to give up the crappy half-written solution you’ve created in favor of a better one you’ve discovered, having already started – out of pride
• You don’t take ANY pride in what you do, and commit crappy code “just to get it done”
• You don’t write any unit tests – you know that something broke when a user notices it
• You write a unit test for EVERYTHING – your build takes longer than it would take to manually execute every usecase, and you’ve likely missed deadlines
• You don’t know enough about the tools available to pick the right ones
• You don’t follow the development of tools within your stack (saw a lot of that with the PHP4->PHP5 transition)
• You don’t ask for input from someone that knows more than you do
• You throw the book at everything – “Gang of Four” etc. are all books, but I think it’s a waste of time to write double the code needed for something, just to say that it follows a certain pattern (this will likely be its own post sometime in the future)
• You don’t learn from past mistakes or refuse to admit they were mistakes
• You give up common sense in favor of dogmatic principles like “Comments are harmful” and “Never write your own framework”

At the end of the day, the last bullet can probably sum up this entire post: use your common sense, and you’ll probably be fine. Naturally, if you’re a moron and lack any semblance thereof, disregard everything I’ve written, find some polarizing views on some blogs, and cherish ‘em like they’re your last pair of clean underpants the day your girlfriend gets back into town.