3 ms·
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
by lostcolony 12y ago
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.
- raverbashing 12y agoThis 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.
- lostcolony 12y agoCertainly. 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
- bluefinity 12y agoOr, 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;
- danbruc 12y agoWhy six hours? This definitely needs another constant.
- mpweiher 12y agoSmalltalk: newTime := currentMillis + 6 hours asMilliseconds.