我们应该在属性名称中加入度量单位吗?

如果你有一个一致的计量单位,那么你的DBA的政策是可以的。

例如,如果时间跨度始终以分钟为单位,等等。

如果计量单位可以更改,则应将其存储在另一列中,与数量一起。

也就是说,我倾向于站在你这边。 我倒想看看 DurationMinutes Duration 并且必须猜出计量单位是多少。

对你应该。

正如查尔斯·布雷塔纳所指出的那样,关键在于易读性,你的表格的其他用户或跟随你的开发者知道你在使用什么。

我绝对会将单位/度量值包含在一个字段名称中——在我的业务中,你无法从上下文或名称中猜出你会发现什么:一个名为MarketValue的字段——是以百万、千或单位为单位的吗?美元、欧元、英镑、货币?这个值是一个百分比,一个比率吗?绝对的还是相对的?每日、每月、日历年、财政年度?那个时间戳是什么时区?

在提供数据时,您的第一个、最后一个也是唯一一个任务是确保数据不会因为消费者无法充分了解数据而被错误使用。作为开发人员,将“米”、“美元”、“格林尼治标准时间”、“百分比”或其他任何东西添加到字段名中一点也不难闻。

在字段命名的细微气味需要标准化之前,有大量的气味需要解决。

这就是为什么 Mars Climate Orbiter 以350米/秒的速度坠入地表,当时计划的速度仅为350英尺/秒(或类似速度)。

按以下格式命名所有我的列的约定:

{name}_in_{unit}

si units 实际上,它最终使我能够推断出列数据类型,并通常简化了我的写作风格。

length_in_m
speed_in_ms-1
color_in_nm

有一些例外情况,我用_at_time或_of _处理:

在某个时间开始 旋转次数

我认为这在任何地方都是一个好主意,因为总是有模棱两可的余地。

例如,对于我们使用的高性能计时器类,我必须不断检查getAppeased()方法是否返回秒、毫秒或其他值。如果它被调用为GetElapsedMilliseconds(),则可以避免混淆。

F#在这方面有一个有趣的转变,允许在类型系统中指定测量单位。看到这个了吗 blog post ,以及另一个正在讨论的问题 Are units of measurement unique to F#?

它比扩展属性更好,这对于普通的开发人员来说并不明显。这比在单独的文档中要好,因为许多开发人员不会阅读它们,当然也不会详细阅读。如果设置了单位,那么将其命名听起来是个好主意。如果更改,则在添加“单位”字段时,更改“测量”字段的名称。

不要在数据库列名中输入度量单位(或列类型)。

许多数据库都能够以某种方式记录/注释列(在SQL Server中是sp_addextendedproperty),我建议这是一个更合适的位置。

对于Python日期时间,考虑使用来自 datetime

int 或 float 相反,强烈建议在变量名称后面加上单位名称缩写。例如,代替变量名 diff diff_secs 几秒钟之内, diff_ms 几毫秒, diff_µs 微秒,或 diff_ns 纳秒。

理想的方法是,如果可能的话,使用一种对测量没有歧义的类型。例如在.NET中,而不是说 int periodInSeconds 你最好使用 TimeSpan period .

10<m/s> 和 5<s> 甚至对它们进行计算,比如 10<m/s> * 5<s> 会导致 50<m> See here for more info .

你肯定想要测量单位

• 有关度量单位的信息存储在哪里?
• 如何以编程方式访问这些单元?

如果答案是“不是”或“你不能”,那就痛苦地抱怨——他们无权拒绝你的命名惯例。否则,如果你在系统内工作,所有人都会更快乐。

另外,我真的很喜欢他们在F#中对度量单位的支持。

我不得不说,我讨厌“描述性”变量名变成“极其冗长”的变量名。

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

话虽如此。如果我正在编写一个度量单位错误非常危险的系统,我可能会使用类型系统并定义一个长度类,它总是将自己转换为任何计算的标准单位。甚至可能是脚、米等的不同子类。

否,属性的名称与其度量单位分开。

如果您调用可变长度_mm,那么您将绑定到mm。

如果使用32位int来存储长度_mm,那么最终以mm为单位的长度可能会大于62000,或者无论32位int的限制是什么。您不能切换到m,因为您将长度变量绑定到长度_mm。

我认为在你的标识符中加入单位是一个很好的选择 设计气味。这几乎肯定意味着您选择了错误的语言:如果单元对项目如此重要,您最好使用类型系统能够表示它们的语言。