“The right code is the code that works right.”
That’s what I said yesterday and I wanted to give an example of how I applied this in my own code just last week.
I was coding yet another dynamic table for an XPage application.
This new use case produces a very different user experience plus I was trying to find a path to significantly reduce the effort required to produce customer deliverables going forward.
The situation called for automatic numbering of rows. The tables and rows are all created dynamically from configuration documents.
So just repeat over the configs and number each row as you go right? There is the Repeat Control Index variable or other mechanisms so how hard could this be?
Well, some rows don’t get numbers. Also, sometimes the next table that gets produced, which may or may not be anywhere near the current table, may or may not continue the numbering from the current table’s rows.
So I started thinking WWTD. You know, What Would Tim Do?
Of course there are several beans and classes involved in this process but the rows are persisted within another object so the row constructors themselves don’t know anything at all about the other rows. Consequently I was mentally concocting all manner of ways to persist “currentRowNumber” and “lastRowNumber” kinds of variables so that I could “do the right thing” by only processing each set of rows in a single pass.
I mean, duh, everyone knows a single pass performs best right? Sheesh!
A “single pass” approach though was going to require meddling with objects and beans higher up the chain and so I decided on a double pass approach even though it felt a little dirty.
All of the rows are created in one pass and each row has an attribute indicating whether or not the “row number” cell actually gets a number or is empty and also indicates if there is a specific starting number for the row.
Using those two properties made it a very simple matter to rip through the rows a second time and number them all appropriately within the code section that was actually creating the table with no changes anywhere else in the architecture.
So in my mind, the right code sort of felt like the wrong code but it was right for the situation plus it met the deadline.
Elegant? Perhaps not. Elegantly simple? Maybe. Will I be changing that code in the future? Unlikely.
“You know, uh, Russ, yesterday you kind of sounded like you weren’t all for Java. What gives?”
On the off chance anyone mistook that as my message (tho’ I think not), I want to make clear that I was already using Java so, uh, ya’ gotta’ keep using Java with your current Java code.
I love using Java. Love it. I think everyone should use Java. Every single time it makes sense.