Sacrificing Orthogonality (code)

[deprecated]

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';

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.

[stephen]

Practical Programmer is indeed a classic-in-the-making.

There's another classic that's well worth reading: Refactoring: Improving the Design of Existing Code. Design will always change as you get further into the code; refactoring gives a methodology for making those changes in a way that is less likely to break existing code.

Absolutely we need to make sure that our code fits our requirements. But I'd prefer to save my compromises for optimization of the code. Constant attention to design is important, just to make sure it's at least a SMOOTH ball of mud. :)

My rule of thumb: keep documentation as close to code as possible. Keep data and formatting as far from code as possible. But no farther. If it's necessary to write code to do the formatting, the formatting code should be in its own class or template, because formatting changes so frequently.

Could you create a "TableFormatter" object with a format_row() method that is called once for each row in a table? Then it could keep track of the table rows without the records themselves having to know which row they are, just by keeping track of what color it used last.

For me, a key to orthagonality is to limit the functionality of each layer. I've recently started learning about XSLT, and one thing that I like about it is how limited it is. There are certain things which are difficult or nearly impossible to do in XSLT, which forces one to do them somewhere else (such as in a Perl script), and have XSLT handle the output reformatting alone. (You could actually handle the alternating-rows problem using XSLT, and then be totally agnostic as regards the underlying dataset.)

Anyway, hope those random musings have some value...

stephen

[Dog and Pony]

I'm afraid I have not much else to offer than: there there, brother dep, thats okay, we all have to make sacrifices in perfection for practicality in the workplace... ;-) Which I by the way do mean seriously...

But I'd like to add that the book you are mentioning is one of the best ones I have read myself, and tip people off that they can visit the website of the authors also for a great read, and also to get a little idea of how good the book is. There are extracts from the book, as well as some great articles and essays, of which the star trek one is a personal favourite.

Haven't been visting that site/read the book in a while, I think it is about time to do that again. :)

Sorry all for the slightly OT post, but that book just makes you happy. :)

---

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.