I've got some neat code that I may node up after I get this small task done. Essentially what it does is print out a table (html) with alternating colors for the "rows" based upon the output of a sql statement.

Consider this:

select whosit, whatsit, wheresit, howsit
  from huh where howsit = 'with the lead pipe' and wheresit = 'in the 
+lavatory';
[download]

this doesnt actually require any labelling other than the columns (whosit, whatsit, wheresit). so the program, as written, just numbers the rows so that coworkers can communicate "on X.cgi at row #53, see how howsit is with the lead pipe but whosit is mr plum?" this is great, and I thought it was a totally orthogonal design.

Orthogonality matters to me because i've been reading The Pragmatic Programmer: From Journeyman to Master lately. It mattered to me before, because I liked to be able to pull a sub out of a script and plug it into another. The book however, stressed that I should be able to change my entire dataset without changing the function that represents my data.

Two months ago, this wouldn't have bothered me. But now, I see that I'm going to tack on another small sub (see "the big ball of mud" school of design), and reduce the orthogonality from where it is (which only works with a broad, but still defined, dataset).

So, back to the matter at hand. The reason this program is getting busted is I have to add a row descriptor where before only columns were necessary. I can pass in another parameter (in the guise of a column that will be the identifier for the rows), but it will be imperfect. I'd rather not do that, but I suspect thats what I'm going to do, to avoid modifying my semiorthogonal code.

What I'm looking for is two things, I guess, from the other programmers in search of perfection at the monastery.

• "there there, brother dep, thats okay, we all have to make sacrifices in perfection for practicality in the workplace..."
• a way to spot things like this in the future. i've been very happy with this code and its reusability until my dataset changed dramatically. how does one anticipate all the possible applications of code theyre writing?

I havent checked to see if the book has been reviewed yet, but I would recommend it to any intermediate to advanced programmer (the wisdom is lost on the inexperienced imo).

brother dep.

--
Laziness, Impatience, Hubris, and Generosity.