views:

126

answers:

8

I was wondering whether others find it redundant to do something like this...

const double RESET_TIME = 0.0;
timeSinceWhatever = RESET_TIME;

rather than just doing

timeSinceWhatever = 0.0;

Do you find the first example to aid in readability? The argument comes down to using magic numbers, and while 0 and 1 are considered "exceptions" to the rule, I've always kind of thought that these exceptions only apply to initializing variables, or index accessing. When the number is meaningful, it should have a variable attached to its meaning.

I'm wondering whether this assumption is valid, or if it's just redundant to give 0 a named constant.

+1  A: 

I would define it only if there was ever a chance that RESET_TIME could be something different than 0.0, that way you can make one change and update all references. Otherwise 0.0 is the better choice to my eye just so you don't have to trace back and see what RESET_TIME was defined to.

bmalicoat
I can see what you are doing if you put 0.0 but it doesn't tell me why and your assuming I know what 0.0 means - not always the case with new developers.
Ralph Willgoss
A: 

Well suppose that RESET_TIME is used often in your code and you want to change the value, it will be better to do it once and not in every statement.

Patrick
A: 

That code is ok. const variable are unchangeable variables. so whenever you feel to reset something, you can always have your const to do that

Treby
+3  A: 

Typically, one benefit of defining a constant rather than just using a literal is if the value ever needs to change in several places at once.

From your own example, what if REST_TIME needed to be -1.5 due to some obscure new business rule? You could change it one place, the definition of the constant, or you could change it everywhere you had last used 0.0 as a float literal.

In short, defining constants, in general, aids primarily in maintainability.

Randolpho
+6  A: 

Well, in your particular example it doesn't make much sense to use a constant.

But, for example, if there was even a small chance that RESET_TIME will change in the future (and become, let's say, 1) then you should definitely use a constant.

You should also use a constant if your intent is not obvious from the number. But in your particular example I think that timeSinceWhatever = 0; is more clear than timeSinceWhatever = RESET_TIME.

Andreas Bonini
Couldn't agree more. Code readability and maintainability are key, particularly when someone else might have to maintain this. Its a good habit to get into, thinking about someone who might not know what these magic numbers mean.
Ralph Willgoss
+2  A: 

If you want to be more specific and letting others know why you're changing doing what you're doing you might want to instead create a function (if your language permits functions to float about) such as

timeSinceWhenever = ResetStopWatch();

or better yet when dealing with units either find a library which has built in function types or create your own. I wouldn't suggest creating your own with time as there are an abundant amount of such libraries. I've seen this before in code if it helps:

Temperature groundTemp = Temperature.AbsoluteZero();

which is a nice way of indicating what is going on.

wheaties
A: 

better than a constant, make it a configuration variable, and set it to a default value. But yes, RESET_TIME is more readable, provided its used more than once otherwise just use a code comment.

Rob Fuller
+1  A: 

Constants are preferable as it allows to use a value that can be then changed in successive versions of the code. It is not always possible to use constants, especially if you are programming in a OO language, and it is not possible to define a constant that doesn't contain a basic datatype. Generally, a programming language always has a way to define not modifiable objects / datatypes.

kiamlaluno