Whenever you store a value that has a unit in a variable, config option or CLI switch, include the unit in the name. So:
maxRequestSize=>maxRequestSizeByteselapsedTime=>elapsedSecondscacheSize=>cacheSizeMBchargingTime=>chargingTimeHoursfileSizeLimit=>fileSizeLimitGBtemperatureThreshold=>temperatureThresholdCelsiusdiskSpace=>diskSpaceTerabytesflightAltitude=>flightAltitudeFeetmonitorRefreshRate=>monitorRefreshRateHzserverResponseTimeout=>serverResponseTimeoutMsconnectionSpeed=>connectionSpeedMbps
EDIT: I know it’s better to use types to represent units. Please don’t write yet another comment about it. You can find my response to that point here: https://programming.dev/comment/219329
That seems akin to commenting. The problem with this approach is that text is not code. It’s very easy to forget to change text. In that case it becomes the worst of both worlds, you have a variable name that actually misleads you.
Much safer than this is to encode this kind of information into the code itself in such a way the program won’t compile of the types are incorrect.
I understand what you mean, and I even agree with it, but just to be a little pedantic, variable names are code, or at least they are more code than comments or docs.
But yes, encoding units into the type system is a much better solution. It doesn’t work however for config options, environment variables or CLI switches.
It does work - you have a function somewhere that converts your environment variable to the correct type, possibly with a default value, throwing an exception if it’s an invalid value (maybe cache size has a minimum of 100MB or the software will be unusable), and has extensive unit tests for the function.