perhaps the coder was in the middle of refactoring this code so that it could be used for any month instead of just december :) Personally I think having the 12's hardcoded in there is a bigger sin than programmatically figuring out that there are 31 days in the 12th month. and the ugly string concatenation that could've been avoided by using a DateTime value and ToString("MM/dd/yyyy")
"I don't know about you, but that grade school rhyme helps me remember which months have how many days. On the occasion that I don't remember that, I'll consult my wall or desk calendar."
I always learned to remember it via the knuckles on your hand: Start at the right or left, doesn't matter. A knuckle is a month with 31 days, in between knuckles is a month not with 31 days :)
What bugs me most here is that "12/" & lastDay & currentYear.Year. This representation for dates has a great potential for i18n bugs. I’d be seriously tempted to test this code in a default non-US English locale (say, Russian with dates as d.MM.yy), my customized settings (Russian but with dates in yyyy-MM-dd), and my “extreme date-formatting testing” settings (dates in yyyy$MM$dd).
And, this developer is being inconsistent; if 12th month can contain !=31 days, a year can contain !=12 months.
I know this is an old story, but the author might have had localization in mind. Not all calendars have 31 days in the 12th month (and some have more than 12 months). We assume Gregorian in the US, but Windows developers may need to support other calendar formats (yes, people really have other calendars besides Gregorian!). Of course, a programmer with localization in mind should probably NOT have hard-coded the date separator and format into the control...