Economy of Effort

I work for a small design studio. Their core business is creating logos, designing signage for corporate events, and all that jazz. Over the past few years, they’ve found clients wanting more and more electronic-based content from them. First it was email blasts and static websites, then they wanted websites that did more than just serve up static content, and pretty soon it became web applications and even small desktop applications. Hence the creation of the job which I now fill.

I wasn’t the first one to fill the job. A couple of guys came before me. My immediate predecessor, we’ll call “Dan”. Dan was not particularly beloved. On the contrary, it was those oh-so-important “people skills” (or lack thereof) that led to his, shall we say, unscheduled exit from the position. My first week on the job ended with me getting the raise that would have been saved for after my 3 month performance review, helped in no small part to solving problems in that first week that had been long-standing issues. Most importantly, I was Not Dan.

I recently read a cute little article linked on Hacker News and reddit: Signs that you’re a bad programmer. A lot of these can be applied to the code Dan left behind. Particularly, #2: “Poor understanding of the language’s programming mode”, and its first symptom: “Using whatever syntax is necessary to break out of the model, then writing the remainder of the program in their familiar language’s style”.

Dan apparently got started as a FORTRAN programmer back in the day. It’s clear that he never really understood PHP. One of the most contentious parts of PHP development is mixing PHP code alongside HTML markup. Whether the HTML is separated out in templates, mixed with inline PHP, stored entirely in echo statements or HEREDOCs, or even just written there in the file after “jumping out” of PHP mode, there’s a number of ways to approach the issue of PHP’s coexistence with HTML markup.

Unfortunately, the language’s flexibility means approaches like Dan’s are possible. Dan clearly never quite wrapped his head around the practices I mentioned above. Instead, his concept of HTML within PHP was to wrap all HTML generation inside of tiny PHP functions. Here’s an example:

startTable("725", "0", "", "id=addTable");
 startRow("center","2","","","noPad");
 if($assId) {
 displayButton("Update Record", "what");
 } else {
 displayButton("Add Job", "what");
 }
 displayButton("Reset", "what", "reset");
 endRow();
 startRow("center","2","","","","top");
 echo "<b>Attach File:&nbsp;</b> ";
 displayFormItem("file", "fileNam");
 displayButton("Upload", "what");
 endRow();

This generates the HTML:

<table width="725" id=addTable border="0" cellpadding="0" cellspacing="0">
<tr><td class=noPad align=center colspan=2>
<input type=submit name="what" value="Update Record">
</td></tr>
<tr><td align=center valign="top" colspan=2>
<b>Attach File:&nbsp;</b> <input type=file name="fileNam" value="">
<input type=submit name="what" value="Upload">
</td></tr>

Yes, instead of simply writing the HTML, everything is stuck in a function. “endRow()”, for example, is literally nothing more than an echo statement for “</td></tr>”. Every tag related to HTML tables has a function, some of which accept a ton of possible arguments for every possible thing you might want to put into that tag (a CSS class, id, border, inline CSS, etc). startRow() takes up to 7 arguments. Reading Dan’s awful code means needing to remember what those arguments are (and what order they’re in), as opposed to simply reading the very clear HTML that they spit out. What are those blanks for arguments #3 and #4 for in the startRow on line 2?  They’re some potential <td> attributes (because, despite being “startRow”, the function echoes <tr> with no attributes, and then echoes the first <td>, and all these attributes belong to that first <td> tag). In this case, they’re attributes that aren’t being used. Which attributes? Who knows? You’d have to go look at the definition of startRow. (Also note: this isn’t a worst-case example. This is a pretty tame example of the kind of crap Dan did like this.)

PHP can be useful in HTML generation – using Zend_Form from the Zend Framework, for example, can be very handy for creating forms with validation. Dan, however, wrapped trivial HTML into PHP functions, providing absolutely no additional value of their own, while unnecessarily increasing complexity and destroying readability.

That’s not the only gift Dan left behind, of course. Relative paths seemed to confuse Dan greatly. That meant the use of a lot of unnecessary absolute paths. It also meant that Dan would take his “lib” folder, which stored all his library code, and copy it into subdirectories so that the relative path “lib/” would still be valid, as opposed to using  “/lib/” or “../lib/” (or, on the HTML side, the <base> tag. Dan and <base> have never met.)

These are just immediate things I ran into today, when fixing some old Dan code. It should come as no surprise that, even ignoring the “WTFs” like these, Dan Code ™ is pretty bad code. None of it is shocking enough to be TheDailyWTF material, but it gets a small moment of recognition here today.

Now I hate Dan too.

(Side note: one of the most frightening parts of entering the work force was doing so with no professional programming experience. I’d been writing code nonstop since entering college, but it was a constant flurry of jumping from language to language, paradigm to paradigm, and no settling in and mastering one development technology. That’s a good academic approach, as it breeds the ability to rapidly pick up new technologies, and develops an understanding that separates a concept from its implementation in a specific language… but it’s no fun to then go out and see job postings wanting X years of experience all centered around one language. That blow is softened when, even in your greenness, you’re still better than the guy that was there before you.)