in reply to Sacrificing Orthogonality (code)

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...