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]
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.
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.
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.
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).
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.
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.
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?
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".