我想我们大多数人都同意为变量,对象属性和数据库列使用描述性名称是个好主意.如果你想存储某些东西的名字,你也可以调用该属性,Name
以便人们知道要放入什么.
如果测量单位不是很明显,我认为你应该更进一步,在名称中包含计量单位.Length_mm
例如,应该有助于提醒开发人员,如果用户刚刚以英寸输入,他们最好将长度转换为mm.
但是,我的数据库管理员告诉我,在数据库列名中包含度量单位是"不受欢迎的".我认为这只是疯了,但也许有一些风险DBA知道我没有.
在这里给我一句话:我们应该在属性名称中嵌入测量单位吗?为什么?为什么不?
如果你有一致的UOM,那么你的DBA的政策就没问题.
例如,如果时间跨度总是在几分钟内,等等.
如果UOM可以更改,那么您应该将它存储在另一列中,与数量一起存储.
也就是说,我倾向于支持你.Clarity胜过大多数事情,包括这个.我宁愿看到DurationMinutes
比Duration
并纷纷猜测该计量单位是什么.
是.你应该.
正如@ [Charles Bretana]指出的那样,关键是易读性,并且您桌子上的其他用户或开发人员会关注您正在使用的内容.
我绝对会将单位/衡量标准纳入一个字段名称 - 在我的业务中,您无法猜测从上下文或名称中可以找到什么:名为MarketValue的字段 - 是数百万,数千还是单位?美元,欧元,英镑,货币?这个值是一个百分比,一个比例?绝对还是相对?每日,每月,日历年,财政年度?那个时间戳,是什么时区?
提供数据时,您的第一个也是最后一个也是唯一的任务是确保不会错误地使用它,因为消费者无法找到足够的数据.作为开发人员,将"Meter","USD","GMT","PerCent"或其他任何东西扔进一个字段名称并不是一点点臭.
在字段命名的微小气味需要标准化之前,需要解决大量气味.
这就是火星气候轨道器以350米/秒的速度撞击地面的原因,计划只能处理350英尺/秒(或类似的东西).
虽然"永远不会说'从不'或'总是'",一般来说,这是一个很好的经验法则,在这里我会弯曲我的规则并说我认为你应该"总是"明确数字值的单位.