3 ms·
always suffix with the unit Heck yeah. One of the few things in this godforsaken industry/craft that I consider to be unambiguously true. for quantities f
by JohnBooty 4y ago
always suffix with the unit
Heck yeah. One of the few things in this godforsaken industry/craft that I consider to be unambiguously true.
for quantities for which we are likely to not always use SI units
Do you mean "likely to not always use SI base units?" Second and millisecond are, for example, both SI units.
Regardless, I think it's worth suffixing all variables with unit type regardless of SI base units or not. This is particularly true for large and/or long lived projects with multiple developers.
Developers are almost always the limiting factor in any development effort.
Therefore, always prioritize reduction of developers' cognitive load unless there is some specific reason not to (ie unrolling a loop for performance reasons, etc)
The only arguments against longer identifier names are non-issues:
1. "They're harder to type." If you're using a code editor without autocomplete in 2022, that's on you.
2. "If I use long identifier names I can't fit as much code on a line." Bit of a coding style smell if this is an issue, IMO.
- jffhn 4y agoYes, SI base, for example second, not powers of tens of it, but we just call it SI. For linear positions no suffix means meters (x, y, z, etc.), same vx is in m/s etc. Autocomplete is nice but in my IDE it requires hitting ctrl+space and then you might have a choice to make.
- wizofaus 4y agoLinear positions with no suffix I'd typically assume were in pixels! Or just unitless cartesian positions.
- jffhn 4y agoAll the domain revolves around things moving around in the real world, there is no pixel. Also at some point, to prevent unit problems, someone tried to add methods for units handling (set value and unit, get value for unit, or get value and unit separately), but it was a train wreck (people setting with fancy units, people getting the raw value assuming SI, and when unit was properly specified to the getter much time was spent in the object oriented and allocation addict units framework, and the code was bloated with units condiderations), so we got rid of that (which could surely be done better, but we thought it was just better without. We just have a few utility functions on the side for the rare cases where we need units conversions).
- wizofaus 4y agoThat says to me you should be using types with strongly-typed units built in (using templates/generics etc). I wouldn't expect to able to call "Set unit" on a quantity though, just a function to convert it and return the new differently typed quantity. Nor would you need "get unit" as it's known at compile time.