Re:Please put units in names
by bombcar on Monday March 21, 2022 @09:55AM
(#30754144)
This is why it's dangerous to encode the unit in the variable, because it will eventually change (we had code that was measured in seconds and had to be changed to measure in 20/ths of a second for more granularity, if the timer variable had been named "timer_seconds" it would have had to be changed everywhere.
[ Parent
| on HN ]
Re:Please put units in names
by RandallBrown on Monday March 21, 2022 @12:31PM
(#30756089)
If you change the unit, I think the variable should be changed everywhere.
It's hard to know what assumptions code is making and by forcing you to change the code everywhere (which should be pretty easy in any modern IDE) you at least have a chance to evaluate any issues that unit change could cause.
Someone doing a half-assed refactor doesn't mean it's "dangerous" to encode a unit in a variable or function.
I do agree that generally it's better to use something like a struct that's more flexible, but doing that for every function is also quite verbose. For some functions the time requirement may never change as well.
Re:Please put units in names
by hallway_monitor on Monday March 21, 2022 @10:13AM
(#30754352)
In this specific case, it seems like creating a new property with the new data in a new name would be the safest path forward. Ensuring the unit are in both property names will prevent confusion.
Re:Please put units in names
by llbeansandrice on Monday March 21, 2022 @12:37PM
(#30756198)
This sounds like a feature to me and modern IDEs make this type of simple refactoring quite straight forward for most languages.