3

I'm working on the data model of a service describing houses and flats. This involves storing quantitative physical properties of certain features of the premises, for example:

  • Speed of the Internet connection in Mbps
  • Length of a swimming pool in meters
  • Noise level of kitchen appliances in dB

The quantities will always be specified and stored in terms of the same units, and there will be no need for performing calculations on them. The most complex operation will be comparing and ordering values of the same unit.

My question is: would you recommend me to use a proper physical units library for storing these quantities, or is it valid to decide that I don't want to depend on a 3rd-party library just for storing some numbers if I won't be performing arithmetic on them, and I know they are always specified using the same units?

H2CO3
  • 437
  • 2
  • 10
  • 6
    KISS because YAGNI – Constantin Galbenu Mar 17 '18 at 19:49
  • @ConstantinGalbenu hah, fair enough! – H2CO3 Mar 17 '18 at 19:49
  • 1
    As long as fellow programmers have a way to lookup / ascertain the physical unit of a particular object field or database column. This can be done with documentation or variable naming. Also, noise level is probably going to be in dB (so, there is no confusion with the unit), but the minor detail that makes a difference is the noise measurement methodology or [test procedure (PDF)](http://epa.tas.gov.au/documents/noise_measurement_procedures_manual_2008.pdf). These don't belong to code, but belong to the policy of those using the software. Perhaps a string comment field may be needed. – rwong Mar 17 '18 at 20:07
  • 1
    @rwong thanks for the feedback! Yes, currently property/field names are annotated with the unit, e.g. `noise_level_db` or `download_speed_mbps`. – H2CO3 Mar 17 '18 at 21:09
  • @rwong: I don't know any "proper physical units libraries", but would the usage of such a beast really reduce the effort they have to invest into proper documentation and variable naming? I cannot really believe this, so I miss to see any real benefit for the described situation. – Doc Brown Mar 17 '18 at 23:04
  • 1
    @DocBrown I would say the main difference between "documentation and variable naming" and "proper physical units library" is that the former is *"human readable, with a bit of information hunting"*, and the latter is *"machine readable, but also requires the human to do a bit of information hunting"*. Modern IDEs aren't resourceful enough to show you the physical units of a variable when you hover the mouse over it. – rwong Mar 17 '18 at 23:49
  • 1
    Remember that the alternative to using a library doesn't have to be using primitive types - you can write your own classes for modeling physical quantities with just the functions you need. – bdsl Mar 18 '18 at 10:05
  • @DocBrown the point of a units library is to preserve type safety with the goal of preventing mistakes related to differing units or nonsensical operations. That is something that definitely benefits from automatized exhaustive checking left to the compiler – it does not eliminate the need for legible code or documentation, but documentation and coding conventions don't *prevent* (albeit reduce) mistakes. Hence, I would argue that the two are orthogonal, and both can be necessary. – H2CO3 Mar 18 '18 at 19:59
  • @bdsl Of course, and I have already considered it. My question was largely if I should invest time in writing my own implementation if it's going to be *very* partial anyway, since partially reinventing the wheel when there's a complete, well-tested, existing solution can often be a sign of bad practice. Apparently, not in this case, but often. – H2CO3 Mar 18 '18 at 20:02

3 Answers3

3

Usually the reason to support multiple units of measure (aside from measuring things) is to support localization or conversions between systems (e.g. miles to kilometers).

The conversions from one unit to another are widely known. I would even argue it is more a matter of localization than anything else. I live in the USA, so my spacial awareness deals mostly with inches, feet, and miles. Someone from Canada (or practically anywhere else on planet Earth) is probably more familiar with the metric system.

So, decide on which one to store. You settled on the metric system. So if you need to localize this system, convert meters (or metres) to feet.

  1. Read from DB
  2. Convert
  3. Display

It follows the same pattern as dates and times, frankly. Dealing with different units of measure in the database does not benefit the application, since conversions are easy if you need to support other measurement systems in the future.

Since a possible refactoring in the future might be localizing the measurement systems, you are good for the time being having designed the system with storing values in one measurement system.

The reason you don't need a library just yet is not to KISS it, or YAGNI --- it's because the cost of refactoring to support other systems is just another form of localization that could be handled in the UI layer of the application. It shouldn't need to be a wide spread gutt-and-rewrite refactoring job.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
1

Just distill the question down to its essence:

Should I use a library for something I don't need.

The answer is obviously no.

whatsisname
  • 27,463
  • 14
  • 73
  • 93
0

As alternate point of view, without the library, a label might have a signature like this: 

String dimensionsLabel(int height, int width);

If this signature appeals to you, it might be less work to use a library than rolling your own types: 

String dimensionsLabel(Meter height, Meter width);
Morgen
  • 1,071
  • 7
  • 10