3 ms·
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
by fleitz 15y ago
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
CalendarFactoryFactorException,
DateOutOfRangeException,
ArrayOutOfBoundsException
{
CalendarFactoryFactory factoryMaker = new CalendarFactoryFactory("Western");
GregorianCalendarFactory gregFactory = factoryMaker.getGregorianFactory();
Calendar c = gregFactory.createCalendar(new DateTime());
return c.getDaysInMonth();
}
- kragen 15y ago> Correctness should be verified by tests not 'looking at the code'. 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.)
- hkolek 15y agoYes, something like that. But better use joda time because the standard API sucks. joda: new DateTime().monthOfYear().getMaximumValue()
- narayanbabu 15y agoOne code review session is equivalent to 100 debugging sessions, so your statement that [Correctness should be verified by tests not 'looking at the code'] is very misleading.