And to keep the discussion interesting, also, 12 seconds is a pretty popular timespan to use when you want something longer than 10, but shorter than 15.
If there was an 84600 with no hinting variable names nearby, anyone reading would have trouble figuring out the author's intention. Any other number (say... 81234) would be unambiguous. In the words of Douglas Crockford, "All that you know about the code is that the programmer was incompetent."
Most operating systems and frameworks don't expose the concept of leap seconds to user code. For example, Unix time is the number of seconds since the epoch ignoring leap seconds, so a program that compares timestamps generated by time() would be correct in assuming that a day is 86400 units of time_t.
86400 seconds is 24 hours. It is surprisingly commonly mis-entered as 84600 seconds, as evidenced by this search. As such, many unintended consequences can ensue.
I wonder if Github will ever reconsider allowing bots [0]. There are bunch of things like this that would be cool to have pull-requests automatically generated for. Security fixes would be another place where I can see bots helping to fix common mistakes.
Yeah, I'd love to help in some way, but the number of results is huge and without bots I'm discouraged from doing anything manually.
Maybe we can create a resource of common typos in numerical constants that would auto-detect by edit distance? But I suppose most people willing to check a resource like that probably already double check their arithmetic. (That said, I've probably had this exact bug somewhere in my coding history, so no shame.)
Yeah, maybe the answer is a hybrid, bots that look for common mistakes and a website that lets people login to github and displays the potential fixes so they can fix the code in the browser and send the pull request. Like a way to try and introduce people to open source through guided fixes more or less.
eh - and what is that supposed to show? That there's roughly 13.000 projects that vendored a version of activesupport containing a file that allows converting "48600" to a rational value?
Honestly, I think there's a little something to this submission beyond the "Ha ha, lots of people made typos that could cause big problems" factor.
A public repository like GitHub makes checks for common errors like this really easy. Would it be feasible for GitHub or the community to automatically recognize broad classes of these likely errors and notify the authors? How sophisticated could that sort of tool become?
I agree, it's too bad they banned bots [0], one alternative I see is:
>> Yeah, maybe the answer is a hybrid, bots that look for common mistakes and a website that lets people login to github and displays the potential fixes so they can fix the code in the browser and send the pull request. Like a way to try and introduce people to open source through guided fixes more or less. [1]
Depends. There's probably 10x more PHP code on Github than any other language, so you're going to find 10x the common mistakes. It could be that there's a close-to-equal distribution of the same mistake among languages. (Though it doesn't help that PHP is probably used 10x more by inexperienced coders)
Is it surprising you didn't take the time and test your assertion? The errors in the PHP files are mostly from a single package that gets bundled and checked in. The first 4 in fact. The last 43 pages are all in a single repo of data files (I can't figure out what they're used for, but hey, I don't need to know everything).
I'm not a php coder any more, but at least blame php for it's actual faults, not for something pulled out of thin air.
To me it's a coding style thing. The argument for 86400 would be, too many operators makes things damn confusing. When your define expands in the preprocessor to a function sixteen operators long, you have made a mess.
I find myself with pre-optimization issues on my new code and define constants multiplied out rather than add that .000000001% extra overhead of doing the multiplication - it's a sickness.
It's actually not that many places where it's wrong: Anything from page 57 to 100 is one repo that does it consistently wrong: https://github.com/sconklin/solardata, then there's quite a few places that are partial matches only (seconds, but not 84600), there's quite a few places where it's a least not obviously wrong (page 38, where it matches on "PHI( 1) +6.18900e+05-7.84600e+05i Hz") and a ton of places that get copied around (the first pages are all bundled versions of the sonata cache interface).
This should never be entered like that. Not only it's prone to typos, it also requires a comment to accompany it.
Since just about every compiler/interpreter folds constants, one should write it as 60 * 60 * 24 which would run without a performance hit.
63 comments
[ 5.1 ms ] story [ 83.8 ms ] thread84600 seconds = typo ;)
This is in languages I use with less robust date logic, of course.
A day is a day, it's not 86400 seconds.
http://en.wikipedia.org/wiki/Daylight_saving_time
[0] http://www.wired.com/2012/12/github-bots/
Maybe we can create a resource of common typos in numerical constants that would auto-detect by edit distance? But I suppose most people willing to check a resource like that probably already double check their arithmetic. (That said, I've probably had this exact bug somewhere in my coding history, so no shame.)
A public repository like GitHub makes checks for common errors like this really easy. Would it be feasible for GitHub or the community to automatically recognize broad classes of these likely errors and notify the authors? How sophisticated could that sort of tool become?
Maybe "given enough bots, most bugs are shallow".
>> Yeah, maybe the answer is a hybrid, bots that look for common mistakes and a website that lets people login to github and displays the potential fixes so they can fix the code in the browser and send the pull request. Like a way to try and introduce people to open source through guided fixes more or less. [1]
[0] http://www.wired.com/2012/12/github-bots/
[1] https://news.ycombinator.com/item?id=7717694
I'm not a php coder any more, but at least blame php for it's actual faults, not for something pulled out of thin air.
Or, are there languages where you can't declare a constant with a multiplication expression?
obviously PHP.
https://wiki.php.net/rfc/const_scalar_exprs
Time makes my brain hurt sometimes.
The compiler is going to do the operation for you.