Earlier quoted context omitted.
I have to say, I think it's easier to verify the correctness of [31, isLeapYear(year) ? 29 : 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31][M-1] than your formula. Even a dictionary wouldn't be bad. And if it were wrong, it would be easier to fix it.
Correctness should be verified by tests not 'looking at the code'. The aforementioned code can never be verified as correct because February requires a year to be present to know the number of days. Doesn't java have a massive calendar library to address exactly these sorts of human questions? I mean sure you'd still be looking at code like: public int getDaysInMonth(DateTime date) throws CalendarFactoryFactorExcepti…
Tests can prove the presence of bugs, but they are (in general) hopelessly inadequate to prove their absence; and once a test finds a bug, you still have to be able to understand what the code is doing in order to fix the bug.
In practice, code inspections and tests find quite distinct sets of bugs with some overlap, so it's valuable to do both of them. That's why all decent programming processes require both.
(This is probably one of the few cases where you could in fact verify that the code is correct by exhaustive testing — but only by comparing it against a known-correct implementation.)