Hacker News Reader

Comment by lostcolony | Hacker News Reader

Agreed. I much prefer the latter, as it tells me not only the value, but the intention.

newTime = currentMillis + 21600000,

I go WTF is that number and is it right,

newTime = currentMillis + SIX_HOURS_IN_MILLIS

and I not only know at a glance what you're doing, I know what the value ought to be, so if you accidentally added/left out a zero, I can actually check it where that const is declared.

View on HN

Or, in a more reusable/flexible way:

  newTime = currentMillis + 6 * HOUR_IN_MILLIS

But an even cleaner solution would be to just use the date/time library for this (depending on the language, of course):

  newTime = currentMillis + TimeSpan.FromHours(6).Milliseconds;

Why six hours? This definitely needs another constant.

This is exactly where the BS starts. So what are you doing next, FIVE_HOURS_IN_MILLIS? Should we do the whole range?

More importantly: Why 6 hours?

The comment by bluefinity gets it right. HOURS_IN_MILLISECONDS is ok, but don't "constant" everything.

Certainly. Though it may be that you only have a single offset due to whatever business rules, and you never use HOURS_IN_MILLISECONDS, it's always either 6*HOURS_IN_MILLISECONDS or some other term. I didn't want to have to think of an actual domain case, but just show an example of when having a clear, named constant rather than a, yes, unchanging, but ultimately not intuitive and easy to get wrong value, is a better choice; I readily admit you can run that down further once you have a real domain. :P

Smalltalk:

newTime := currentMillis + 6 hours asMilliseconds.

Reply on news.ycombinator.com