More Rubyisms that are Back to Haunt Us
I really don't like the "shortcuts" a lot of people put into code. They don't really make it more readable, and they certainly make it a lot more brittle. Case in point, today I realized that the code in a rule was written:
if days_since_assignment && days_since_activity # do something end
where these variables/methods are nil for those times when there is no respective date. This seems OK, but it's really not. In order to do a good, robust, check, we need to see if it's not nil and then check the value or include it in an inequality. There's no other way.
Now your typical Ruby Code Monkey will say "No! That's not the Ruby Way!" and they'd be right, and the Ruby Way is, in this instance, horrible for so many reasons.
I'm a fan of making things comparable wherever possible, and that means get rid of the nils. Make it simpler - use Float::INFINITY for the return value of a "days since" method if the date doesn't exist. At least that way, it makes sense in all comparisons, and it's at least no worse in some edge cases for testing values. Most often times, it's exactly what you want.
So I had to go in and change what appeared to be "working" code to something that actually worked as intended all because of this desire to minimize typing. Had the original author said:
if !days_since_assignment.nil? && !days_since_activity.nil? # do something end
then at least it would be clear what was going on. Returning an INFINITY now makes it clear that we're never going to fail these checks as a nil is never a possible value.
It's all this maturity that I see missing: no comments… minimal typing… over the top refactoring… fascination with new and shiny things… I believe these guys could be great, but they limit themselves and they don't have to. They can see what they should be doing, and they even know they should be doing it. But they choose not to.
I wish they didn't make that choice.