Should we put units of measurements in attribute names?

Question

I think most of us agree that it's a good idea to use a descriptive name for variables, object attributes, and database columns. If you want to store something's name, you may as well call the attribute Name so people know what to put in it.

Where the unit of measurement isn't immediately apparent, I think you should go a step further and include the unit of measurement in the name. Length_mm, for example, should help remind developers that they'd better convert the length to mm if the user just entered it in inches.

My database administrator, however, just told me that including units of measurement in database column names is “frowned upon”. I think that's just nuts, but perhaps there's some risk DBAs know about that I don't.

Throw me a line, here: should we embed units of measurement in our attribute names? Why? Why not?

Answer 1

If you have a consistent UOM for things, then your DBA's policy is OK.

For example, if timespans are ALWAYS in minutes, etc.

If the UOM could change, then you should store it in another column, alongside the qty.

That said, I tend to side with you on this. Clarity trumps most things, including this. I'd rather see DurationMinutes than Duration and have to guess what the UOM is.

Answer 2

I think this is a good idea anywhere there is room for ambiguity.

For example, the with high performance timer class we use, I keep having to check if the GetElapsed() method returns seconds or milliseconds or something else. If it were called GetElapsedMilliseconds() that would save the confusion.

The only downside being if you wanted to change your mind ... but in that case any clients would need to know about the change anyway.

F# has an interesting twist on this allowing measurement units to be specified in the type system. See this blog post, and another stackoverflow question discussing Are units of measurement unique to F#?

Answer 3

Where the unit of measurement isn't immediately apparent, I think you should go a step further and include the unit of measurement in the name. Length_mm, for example, should help remind developers that they'd better convert the length to mm if the user just entered it in inches.

You could go even a step further (in your code, not in the database) and have a Lenght type, which takes care of the measurement unit and of possible conversions. This is the approach of the "Quantity" pattern in Martin Fowler's "Analysis Patterns" book.

Answer 4

NO, the name of the attribute is seperate from its unit of measurement.

If you call a variable length_mm then you are tied to mm.

what if you use a 32bit int to store length_mm, eventually the length in mm may get larger then 62,000, or whatever the limit is on 32bit ints. You cant switch over to m cause you tied you length variable to length_mm.

Answer 5

We don't put units of measurement in column names in our database. We do, however, have a data dictionary document where all of the columns and relationships are described.

Answer 6

Do not put units of measurement (or column type) in your database column names.

Many Databases have the ability to document/comment columns in some way (in SQL Server it is sp_addextendedproperty), I would suggest that is a more appropriate place.

Answer 7

This is why the Mars lander crashed into the surface at 350 meters/sec when it was planned to only handle 350 ft/sec (or something like that).

Although Never say "Never" or "Always" is, in general, a good rule of thumb, here I will bend ny rule and say I think you should "always" make it clear what units a numeric value is in.

Answer 8

The convention of naming all my columns in the format:

{name}_in_{unit}

helped for one project, since I was using si units it actually ended up allowing me to be able to infer the column data type and generally simplify my writing style.

length_in_m
speed_in_ms-1
color_in_nm

there were a few exceptions that I handled either with _at_time or number_of_:

started_at_time updated_at_time number_of_rotations

Answer 9

The ideal approach is, if possible, to use a type that leaves no ambiguity as to the measurement. For example in .NET rather than saying int periodInSeconds you'd be much better off using TimeSpan period.

The F# language actually has units of measurement as part of the type system so you can declare types in units such as 10<m/s> and 5<s> and even perform calculations on them so something like 10<m/s> * 5<s> would result in 50<m>. See here for more info.

So I'd say if possible use a type that conveys your intention, but if that isn't possible then you should probably encode the measurement into the name. It's better and more obvious than a comment.

Answer 10

I have to say, I hate "descriptive" variable names becoming "incredibly verbose" variable names.

My preferred alternative is to use nothing but the unit-of-measure names in short functions. Eg.

function velocity(m, s) {
   return m/s;
}

You don't need to say "length_m" because in this context, it's obvious that only lengths are measurable in metres.

Having said that. If I was writing a system where units of measure errors were really dangerous, I'd probably use the type system and define a Length class which always converted itself into a standard unit for any calculation. Maybe even different sub-classes for Feet, Metres etc.

Answer 11

I've done a lot of database work, and I would not frown upon that at all, nor have I heard of frowning on it.

It's better than the extended properties, which is not apparent to the casual developer. It's better than in a separate document, because many developers won't read them, and certainly not in great detail. If the units are set, then having it in the name sounds like a good idea. If that changes, then when the unit field is added, change the name of the measurement field.

Answer 12

You definitely want units of measurement somewhere. I don't know if the column names are a good place or if the schema is better. Ask your database administrator

• Where is the information about units of measure stored?
• How can I get access to the units programmatically?

If the answers are "it isn't" or "you can't", complain bitterly---they have no right to deny you your naming convention. Otherwise, all may be happier if you work within the system.

P.S. I really like the support for units of measure that they've put into F#.

Answer 13

I think putting units in your identifiers is a huge design smell. It almost surely means that you chose the wrong language: if units are so important to the project, you'd better be using a language whose type system is capable of representing them.

Answer 14

Yes. You should.

The key, as @[Charles Bretana] pointed out, is legibility and that the other users of your table or developers following you know what you're using.

I would absolutely involve the units/measurement in a field name - in my business you can't guess what you'll find from the context or name: a field entitled MarketValue - is that in millions, thousands or units? US Dollars, Euros, pounds, $CURRENCY? Is that value a percentage, a ratio? Absolute or relative? Daily, monthly, calendar year, financial year? That timestamp, what time zone is it?

Your first, last and only task when providing data is to ensure that it isn't used incorrectly because the consumer wasn't able to find out enough about it. As developers, throwing "Metre", "USD", "GMT", "PerCent" or whatever into a field name isn't the least bit smelly.

There are enormous smells that need resolving before the tiny whiff of field naming needs standardising.