4 ms·
I love this function returnFalse () {return false} and the fact that their home cooked date_val() function does not use their home cooked isLeapYear(
by rgj 6y ago
I love this
function returnFalse () {return false}
and the fact that their home cooked date_val() function does not use their home cooked isLeapYear() and daysInMonth() functions, but uses its own, pretty much unreadable, leap year determination algorithm.
var l_k=parseInt(l_y%100)
var l_m=parseInt(l_y/100)
if (l_d == 29 && ((l_y/4)!=parseInt(l_y/4)))
{
l_err=1 ;
l_errstring = "Date is invalid.";
}
if(l_k ==0){
if (l_d == 29 && ((l_m/4)!=parseInt(l_m/4)))
{
l_err=1 ;
l_errstring = "Date is invalid.";
}
}
- jakub_g 6y agoSee my comment on returnFalse: https://news.ycombinator.com/item?id=26473819 https://news.ycombinator.com/item?id=26473819
- rgj 6y agoNever knew. Cool to know, thanks.
- jiofih 6y agoYeah they would be much better off importing a few npm packages for that, and setting up some CI to build this with webpack and deploy to serverless /s Nothing wrong with the code per se - a little formatting and nicer variable names would make it entirely readable. Having the entire logic inline might be intentional so you can cross-check (legal) requirements and avoid transitive dependencies - the handling of dates specified might not necessarily match what’s “technically correct” at all times. Anyone writing Go will be familiar with this style.