我认为我们大多数人都同意为变量、对象属性和数据库列使用描述性名称是个好主意。如果你想存储一些东西的名字，你也可以调用属性Name，这样人们就知道该放什么了。
如果计量单位不是很明显，我认为您应该更进一步，在名称中包含计量单位。例如，Length_mm 应该有助于提醒开发人员，如果用户刚刚以英寸为单位输入长度，他们最好将长度转换为 mm。
然而，我的数据库管理员刚刚告诉我，在数据库列名称中包含计量单位是“不受欢迎的”。我认为这只是 坚果，但也许 DBA 知道一些我不知道的风险。
在这里给我一句话：我们应该在属性名称中嵌入度量单位吗？为什么？为什么不？
【问题讨论】：
如果您对事物有一致的 UOM，那么您的 DBA 的政策是可以的。
例如，如果时间跨度总是以分钟为单位，等等。
如果 UOM 可以更改，则应将其存储在数量旁边的另一列中。
也就是说，我倾向于在这方面支持你。 清晰度胜过大多数事情，包括这一点。我宁愿看到DurationMinutes 而不是Duration 并且必须猜测UOM 是什么。
【讨论】：
是的。你应该。
正如@[Charles Bretana] 指出的那样，关键是易读性，并且您的桌子的其他用户或跟随您的开发人员知道您在使用什么。
我绝对会在字段名称中包含单位/度量 - 在我的业务中，您无法从上下文或名称中猜测您会发现什么：名为 MarketValue 的字段 - 是以百万、数千还是单位为单位？美元、欧元、英镑、$CURRENCY？该值是百分比还是比率？绝对的还是相对的？每日、每月、日历年、财政年度？那个时间戳，是哪个时区？
在提供数据时，您的第一个、最后一个也是唯一的任务是确保不会因为消费者无法充分了解它而错误地使用它。作为开发人员，将“Metre”、“USD”、“GMT”、“PerCent”或其他任何内容放入字段名称中一点都不难闻。
在字段命名的微小气味需要标准化之前，需要解决大量气味。
【讨论】：
这就是为什么Mars Climate Orbiter 以 350 米/秒的速度坠毁在地面上，而它原本计划只能处理 350 英尺/秒（或类似的速度）。
虽然“从不说‘从不’或‘总是’”一般来说是一个很好的经验法则，但在这里我会改变我的规则，说我认为你应该“总是”明确数值的单位是什么在。
【讨论】：
按以下格式命名我的所有列的约定：
{name}_in_{unit}
帮助了一个项目，因为我使用的是si units，它实际上最终让我能够推断列数据类型并通常简化我的写作风格。
length_in_m
speed_in_ms-1
color_in_nm
我使用 _at_time 或 number_of_ 处理了一些异常：
开始时间 更新时间 number_of_rotations
【讨论】：
我认为这在任何地方都是一个好主意，因为总是有模棱两可的余地。
例如，我们使用的高性能计时器类，我一直需要检查 GetElapsed() 方法是否返回秒或毫秒或其他值。如果它被称为 GetElapsedMilliseconds() 将避免混乱。
唯一的缺点是，如果您想改变主意......但在这种情况下，任何客户都需要知道改变。
F# 对此有一个有趣的转折，允许在类型系统中指定测量单位。请参阅此 blog post，以及另一个讨论 Are units of measurement unique to F#? 的 stackoverflow 问题
【讨论】：
我做过很多数据库工作，我完全不会对此感到不满，我也没有听说过对此感到不满。
它比扩展属性更好，这对于临时开发人员来说是不明显的。它比单独的文档要好，因为许多开发人员不会阅读它们，当然也不会很详细。如果设置了单位，那么在名称中包含它听起来是个好主意。如果改变了，那么在添加单位字段时，更改测量字段的名称。
【讨论】：
如果计量单位不是很明显，我认为您应该更进一步，在名称中包含计量单位。例如，Length_mm 应该有助于提醒开发人员，如果用户刚刚以英寸为单位输入长度，他们最好将长度转换为 mm。
您甚至可以更进一步（在您的代码中，而不是在数据库中）并拥有一个 Length 类型，它负责测量单位和可能的转换。这是 Martin Fowler 的“分析模式”一书中的“数量”模式的方法。
【讨论】：
不要在数据库列名中加入度量单位（或列类型）。
许多数据库能够以某种方式记录/注释列（在 SQL Server 中它是 sp_addextendedproperty），我建议这是一个更合适的地方。
【讨论】：
对于 Python 日期时间，请考虑使用 datetime 包中的对象。这样做会将单位隐含地捕获到微秒分辨率。那么在变量名中包含单位就没有依据了。
如果必须改用int 或float，强烈建议在变量名后面加上单位名称缩写。例如，不要使用变量名 diff，而是使用 diff_secs 表示秒，使用 diff_ms 表示毫秒，使用 diff_µs 表示微秒，或使用 diff_ns 表示纳秒。
【讨论】：
我们不会在数据库的列名中放置计量单位。但是，我们确实有一个数据字典文档，其中描述了所有列和关系。
【讨论】：
如果可能的话，理想的方法是使用对测量没有歧义的类型。例如，在 .NET 中，与其说int periodInSeconds，不如使用TimeSpan period。
F# 语言实际上将度量单位作为类型系统的一部分，因此您可以以10<m/s> 和5<s> 等单位声明类型，甚至对它们执行计算，因此10<m/s> * 5<s> 之类的结果将导致@987654327 @。 See here for more info.
所以我会说，如果可能的话，请使用能传达您意图的类型，但如果这不可能，那么您可能应该将测量值编码到名称中。这比评论更好更明显。
【讨论】：
您肯定想要某处的计量单位。我不知道列名是一个好地方还是架构更好。询问您的数据库管理员
如果答案是“不是”或“你不能”，请痛心抱怨——他们无权否认你的命名约定。否则，如果您在系统中工作，一切可能会更快乐。
附：我真的很喜欢他们在 F# 中加入的对度量单位的支持。
【讨论】：
我不得不说，我讨厌“描述性”变量名变成“非常冗长”的变量名。
我首选的替代方法是在短函数中只使用度量单位名称。例如。
function velocity(m, s) {
return m/s;
}
您不需要说“length_m”，因为在这种情况下，很明显只有长度可以以米为单位。
话虽如此。如果我正在编写一个测量单位错误非常危险的系统，我可能会使用类型系统并定义一个 Length 类，该类总是将自身转换为任何计算的标准单位。甚至可能是英尺、米等不同的子类。
【讨论】：
不，属性的名称与其测量单位是分开的。
如果你调用一个变量 length_mm 那么你就绑定到 mm。
如果您使用 32 位 int 来存储 length_mm，最终以 mm 为单位的长度可能会变得大于 62,000，或者任何 32 位 int 的限制。您无法切换到 m，因为您将长度变量绑定到 length_mm。
【讨论】：
我认为在你的标识符中加入单位是一种巨大的设计味道。这几乎肯定意味着您选择了错误的语言：如果单位对项目如此重要，那么您最好使用其类型系统能够表示它们的语言。
【讨论】：