MILLISEC_PER_SEC is never needed
-
Damn. I was hoping you knew of one! ;)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
U+035E s͞e͞e͞m͞s͞ to work... OH, not sure how it works in HTML....
<sig notetoself="think of a better signature"> <first>Jim</first> <last>Meadors</last> </sig>
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
It depends on what it is used for. It could be set to other values to speed up or slow down the time counting without changing other modules. If you develop PLC virtualizations, emulators or firmware that value may be fundamental instead of useless.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
I blame the Brits for that one.
cheers Chris Maunder
You'd better blame the french, and the long scale was the original.
Wrong is evil and must be defeated. - Jeff Ello
-
A counterargument. Excellent. My counter-counter argument, and the reason my brain popped: I would always prefer to have something like
var timeInSeconds = X;
var timeInMilliseconds = timeInSeconds / 1000;My point is that the 1000 is always 1000. The variables surrounding that should be the ones clearly named. The "1000" can never be anything other than 1000. At least that's what I think.
cheers Chris Maunder
-
So: What if you then had
var kiloWattPerHourPerHour = X;
var kiloWattPerHourPerMinute = kiloWattPerHourPerHour / 60;Should the 60 be a constant or a literal?
cheers Chris Maunder
Eeeeh... kW per hour per hour? In which situations does that unit occur? When does kW per hour occur? A constantly rising (or falling) power, at a rate of x kW/h? And then you want to a unit for how much, in kW, the power has risen in one hour. You don't want to simply call it kW, these are not 'absolute' kilowatts, but a change in power, and that is a change per hour over a period of an hour, which is a different kind of kW unit. Then you want the unit of the increase in power for each minute, right? You come across the strangest units if you look around :-) When I was a student, we did some filter calculations where I (after years of wondering) saw how a frequency correction could be given by a time value (European FM pre-emphashis is 50 us, US radios use 75 us - or is it the other way around?), but I never got it under my skin; it is just a strange artifact of unit arithmetics! If you change that 60 to NumberOfMinutesPerHour, the question is: Are these really the same MinutesPerHour as when you measure 'absolute' time progression? Or, do these MinutesPerHour have a slightly different semantics from the wall clock's minutes per hour (similar to a kW value indicating a change in kiloWattPerHourPerHour is different from an instantaneous, or constant, power kilowatt value)? Maybe it should be called NumberOfMinutesPerHourWhenCalculatingChangesInPowerOverTime? When we updated our programming guidelines, the project leader of our project immediately granted an exception from the 80 char maximum line length: Our rules for how to construct 'const' names (this was K&R C) led to serveral cases of identifiers of length >80. Finally, there is the famous Xerox Fortran manual quote:
"The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable pi can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change."
-
It depends on what it is used for. It could be set to other values to speed up or slow down the time counting without changing other modules. If you develop PLC virtualizations, emulators or firmware that value may be fundamental instead of useless.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
In such a situation, the constant is badly mis-named. Calling it a constant, if you intend to vary it, is a small detail. Setting MILLISECONDS_PER_SEC to 2000? Seriously? Which time-dependent operations would that affect - those where milliseconds are used, those where other milliseconds are used? Or all? Would it double or half the speed? A properly named semi-constant value would be something like SLOWDOWN_FACTOR or VIRTUAL_TIME_TO_REAL_TIME. And while I am at it: I really hate this C style CONSTANTS_IN_ALL_UPPER_CASE rule - much because I have seen too many cases where functional extensions requiring the symbol defintion to be changed to a a variable to adapt to other situations - but the old UC name was used in so many source files and documentation that it cost too much to change it, and the old UC name was retained for the variable. (I also had my first serious programming training in Pascal, and when switching to C, I really missed the option to replace a semi-const/variable definition with a (parameterless) function call - parentheses were not required in Pascal, but in C you have to go through every use and add () to every use of the symbol.)
-
In such a situation, the constant is badly mis-named. Calling it a constant, if you intend to vary it, is a small detail. Setting MILLISECONDS_PER_SEC to 2000? Seriously? Which time-dependent operations would that affect - those where milliseconds are used, those where other milliseconds are used? Or all? Would it double or half the speed? A properly named semi-constant value would be something like SLOWDOWN_FACTOR or VIRTUAL_TIME_TO_REAL_TIME. And while I am at it: I really hate this C style CONSTANTS_IN_ALL_UPPER_CASE rule - much because I have seen too many cases where functional extensions requiring the symbol defintion to be changed to a a variable to adapt to other situations - but the old UC name was used in so many source files and documentation that it cost too much to change it, and the old UC name was retained for the variable. (I also had my first serious programming training in Pascal, and when switching to C, I really missed the option to replace a semi-const/variable definition with a (parameterless) function call - parentheses were not required in Pascal, but in C you have to go through every use and add () to every use of the symbol.)
Member 7989122 wrote:
I really hate this C style CONSTANTS_IN_ALL_UPPER_CASE
I really love it as it makes very clear what I'm looking at :D
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
That's what I would think, as the SI-system is fairly logical. Then you meet someone from the UK and they tell you there's x feet in an inch. It's also a nice shortcut, to change the display from msec to sec, just by setting this constant to "0" instead of "1000" :p
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Surely the constant should change to 1 not 0? It's a scale factor not an offset
Ken
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
If I'm analysing a time based data stream I may wish to record how many milliseconds worth of a data I am processing per second. This information would be crucial for scaling the services doing the processing.
-
Surely the constant should change to 1 not 0? It's a scale factor not an offset
Ken
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
MILLISEC_PER_SEC is actually a conversion factor between some underlying time measurement and seconds - the name suggests it is milliseconds, but it might not be, and it might change. Some old computer hardware only kept time in power line frequency of 50 or 60 hz, and some future hardware (or OS) might keep time intrinsically in nanoseconds. Having a symbolic constant in this conversion, instead of a magic number 1000, makes it perfectly clear what the semantics of the conversion are, which is a good thing.
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
I disagree - I have done such things often. If you are writing software for an embedded system, it will often happen that the basic time tick is close to but not exactly a millisecond: for instance, with a 1MHz clock and a clock divider of 1024 you get 1.024 msec. You can still think of this as a millisecond, which is close enough for some purposes. But if you want to scale to a longer time period, you get errors. For instance, there are about 977 of your "milliseconds" in a second. So defining MILLISEC_PER_SEC as 977 is quite reasonable. Then 60 "seconds" is only off by .027 seconds. If you used the nominal 1000 "msec" per "sec", you'd be off by 1.44 seconds.
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
It may never be actually needed, but it's better than having a lurking special value, repeated throughout the code, of 1000. It communicates something about wherever it's being used -- probably to convert a seconds value to / from milliseconds. I'm for the constant - for easy-to-grok code.
-
Eeeeh... kW per hour per hour? In which situations does that unit occur? When does kW per hour occur? A constantly rising (or falling) power, at a rate of x kW/h? And then you want to a unit for how much, in kW, the power has risen in one hour. You don't want to simply call it kW, these are not 'absolute' kilowatts, but a change in power, and that is a change per hour over a period of an hour, which is a different kind of kW unit. Then you want the unit of the increase in power for each minute, right? You come across the strangest units if you look around :-) When I was a student, we did some filter calculations where I (after years of wondering) saw how a frequency correction could be given by a time value (European FM pre-emphashis is 50 us, US radios use 75 us - or is it the other way around?), but I never got it under my skin; it is just a strange artifact of unit arithmetics! If you change that 60 to NumberOfMinutesPerHour, the question is: Are these really the same MinutesPerHour as when you measure 'absolute' time progression? Or, do these MinutesPerHour have a slightly different semantics from the wall clock's minutes per hour (similar to a kW value indicating a change in kiloWattPerHourPerHour is different from an instantaneous, or constant, power kilowatt value)? Maybe it should be called NumberOfMinutesPerHourWhenCalculatingChangesInPowerOverTime? When we updated our programming guidelines, the project leader of our project immediately granted an exception from the 80 char maximum line length: Our rules for how to construct 'const' names (this was K&R C) led to serveral cases of identifiers of length >80. Finally, there is the famous Xerox Fortran manual quote:
"The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable pi can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change."
Member 7989122 wrote:
should the value of pi change
Yep - one of my all time favourites that one :)
cheers Chris Maunder
-
Well, obviously; they're measured in barleycorns[^]. Everybody knows that! :laugh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I learned not only a valuable unit today. This link enriched my view of the metric/non-metric systems. Very useful graphic[^]. Now I realize why it is so for a person familiar with all this to discover the metric system.
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
Yes; but otherwise "1000" becomes a "magic number". Perhaps a little anal, but if one's intention is to be consistent... Some (scientific) apps treat seconds as a "double"; how else does one convert from milliseconds?
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
Sure it is. Imagine a clock that is gradually slowing down. Its rate of slowing down could be described in milliseconds per second.
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
Documentation wise it isn't totally ridiculous. So something like the following is more obvious than with the real value. timeToProcess = runTime/MILLISEC_PER_SEC To be fair, myself I would probably have coded the above like the following timeToProcessSeconds = runTimeMillis/MILLISEC_PER_SEC But lots of times others do not. And I would rather see the hint.
-
I put it to you that a variable, constant or define named "MILLISEC_PER_SEC" is never, ever, ever needed.
cheers Chris Maunder
If you have measurement-illeterate members on your team, it's rather needed indeed. Sure, to everyone with even a bit education in engineering, "milli" is clearly E-3. But to everyone else, not so much. Heck, I've seen people stumbling over "1,2 k€" which is still rather clear to me.
