Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub search for 84600 seconds. Oops.

github.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: GitHub search for 84600 seconds. Oops.

#41

Post by wdewind »

Steuard wrote: post #27

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…

Yes, in fact Amazon already does this. It will frequently warn you if your AWS keys are published in Github.

Re: GitHub search for 84600 seconds. Oops.

#42

Post by peterwwillis »

[deleted] wrote: post #31

[deleted]

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)

Re: GitHub search for 84600 seconds. Oops.

#43

Post by underyx »

markcarlson wrote: post #33
tshaddox wrote: post #20

Earlier quoted context omitted.

I liked this one: SECONDS_PER_23_5_HOURS = 84600

That is a very common value to use when you want something to either occur a bit more than once a day, or time out in a bit less than a day.

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.

Re: GitHub search for 84600 seconds. Oops.

#44

Post by Xylakant »

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).

Re: GitHub search for 84600 seconds. Oops.

#45

Post by mappu »

zemo wrote: post #38
strommen wrote: post #32

HN Challenge: name a scenario in which defining a constant as 86400 is better then defining it as (60 * 60 * 24). Or, are there languages where you can't declare a constant with a multiplication expression?

> are there languages where you can't declare a constant with a multiplication expression? obviously PHP. php > const X = 1; php > echo X; 1 php > const Y = 1 * 2; Parse error: parse error, expecting `','' or `';'' in php shell code on line 1 php > echo Y; Y

Fixed in the (upcoming) PHP 5.6.

https://wiki.php.net/rfc/const_scalar_exprs

Re: GitHub search for 84600 seconds. Oops.

#47

Post by nkozyra »

markcarlson wrote: post #33
tshaddox wrote: post #20

Earlier quoted context omitted.

I liked this one: SECONDS_PER_23_5_HOURS = 84600

That is a very common value to use when you want something to either occur a bit more than once a day, or time out in a bit less than a day.

I certainly have some code that adds 86399 to encompass the entirety of the day.

This is in languages I use with less robust date logic, of course.

Re: GitHub search for 84600 seconds. Oops.

#49

Post by ggreer »

markcarlson wrote: post #33
tshaddox wrote: post #20

Earlier quoted context omitted.

I liked this one: SECONDS_PER_23_5_HOURS = 84600

That is a very common value to use when you want something to either occur a bit more than once a day, or time out in a bit less than a day.

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."

Re: GitHub search for 84600 seconds. Oops.

#50

Post by Xylakant »

[deleted] wrote: post #31

[deleted]

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.

Post reply on HN