"We had a coder for our project named Clyde," Robert B. writes, "who would have been much happier coding in C, but we had good reasons for choosing VB instead. To make up for the ease of coding in VB, Clyde would eschew the simple way of doing things. No calls to well-defined common routines for him; no, he would code deeply inscrutable functions to accomplish even the simplest tasks.

"Eventually, it came time to move the application to a new, web-based platform. We weren't porting the code – after a decade of Rapid Application Development, it was an unholy amalgamation of conflicting 'common' routines and wildly divergent programming styles. But we did have to document the functionality behind the existing system.

"A colleague and I spent half a day trying to figure out this one check:

bSkipYearCheck = False
If Year((CVDate(datYrEnd_Dt) + 1)) - 1 = iYear Then
    bSkipYearCheck = True
End If

"We finally determined that the only time bSkipYearCheck would be True would be if the date was 12/31/(iYear). Or to be more specific, it would only be true if the date was the last day of iYear: Add one to the date, get the year, subtract one from that year, and see if it matches the current year.

"Why not just check on datYrEnd_Dt = 12/31/(iYear)? There's only one reason we could think of. Clyde wanted his function to be future-proof. Over time, the Earth's orbit will expand, and eventually December might have 32 days, or even more! But even as the planet is being evaporated in the outer atmosphere of an expanding red giant, Clyde's code will correctly tell whether we are at the last day of the year, and can skip the year check later in the routine."