4 ms·

The number of seconds per hour probably won't change, but repeating `// seconds per hour` as a comment everywhere you use the number 3600 seems a little silly w

The number of seconds per hour probably won't change, but repeating `// seconds per hour` as a comment everywhere you use the number 3600 seems a little silly when you can just use a constant. The next programmer doesn't need to see those digits at all, they're nothing but a distraction.

silverbax88 12y ago
I think you're making the point of the parent commenter, which is that getting a bunch of devs to agree on the 'best' way to write code ends up in a nitpicking session. That's been my experience. I've yet to work on or with a team that has been able to resolve the concept of a consistent coding standard.
arethuza 12y ago
Personally, I think it's the "repeating" part that is important - if you use it once then have 3600 explained with a comment, if for some reason you use the same 3600 a lot in a chunk of code make it a sensibly named constant.
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 ago
  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.
  - lostcolony 12y ago
    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
- bluefinity 12y ago
  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;
  - danbruc 12y ago
    Why six hours? This definitely needs another constant.
- mpweiher 12y ago
  Smalltalk: newTime := currentMillis + 6 hours asMilliseconds.
raverbashing 12y ago
> but repeating `// seconds per hour` as a comment everywhere you use the number 3600 seems a little silly when you can just use a constant Yes, so if it's only one case you can have the comment Now, if you're doing it a lot of times I bet your problem is bigger than just adding a constant, it may be even better to turn this into a function so you do to_seconds(time_in_hours) or something

silverbax88 12y ago

I think you're making the point of the parent commenter, which is that getting a bunch of devs to agree on the 'best' way to write code ends up in a nitpicking session. That's been my experience. I've yet to work on or with a team that has been able to resolve the concept of a consistent coding standard.

arethuza 12y ago

Personally, I think it's the "repeating" part that is important - if you use it once then have 3600 explained with a comment, if for some reason you use the same 3600 a lot in a chunk of code make it a sensibly named constant.

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 ago
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.
- lostcolony 12y ago
  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
bluefinity 12y ago
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;
- danbruc 12y ago
  Why six hours? This definitely needs another constant.
mpweiher 12y ago
Smalltalk: newTime := currentMillis + 6 hours asMilliseconds.

raverbashing 12y ago

> but repeating `// seconds per hour` as a comment everywhere you use the number 3600 seems a little silly when you can just use a constant Yes, so if it's only one case you can have the comment Now, if you're doing it a lot of times I bet your problem is bigger than just adding a constant, it may be even better to turn this into a function so you do to_seconds(time_in_hours) or something