命名数据键的最佳做法是什么？

Question

我一直在想是否存在命名数据键的“最佳实践”，也许更重要的是，是否存在任何命名这些条目的标准方法。

我所看到的大多数格式类似于以下格式：

• datakeyone
• dataKeyOne
• data-key-one
• data_key_one

但是，有没有标准或推荐的方法，如果没有（或有多种方法），每种方法的优缺点是什么？

Answer 1

通常， 一致的命名是最重要的事情-无论采用或创建的标准，只有严格使用它，才有价值。

在此之后，关键的是诸如好，简单，拼写正确的有意义名称之类的基本内容。 我会避免使用连字符，破折号，空格，数字，下划线和特殊字符-它们只是增加了名称的长度，而没有提供任何好处。

如果可能，您应该使用名称来表示数据类型。 在您的示例中，数据密钥一，但是您编写它并没有多大意义-确保名称有意义和一致性一样重要。

只要始终使用驼峰式大小写，这是一个好习惯-一条简单的规则（例如“在每个术语中只用大写字母写第一个字符”）是好的。 它可读性强，无需任何其他字符即可显示分词。

初始化或缩写的术语应使用所有大写字母-除非它们的长度超过两个字母，在这种情况下，应使用标准的驼峰式大写字母。

这些规则虽然不是任何标准的一部分，但它们是可靠的，并且在您提到的语言中应该可以正常工作。

这是一些使用上述规则并带有注释的示例，以显示优缺点。

坏键：应避免

• data_key_one（好的，我有数据密钥一...但是什么是数据密钥一！？）
• HTTPAddress（HTTPA序列很难阅读，术语不清楚）
• CustomerId（ID不应像这样驼峰大小写）
• usersexchanged（是“用户性别已更改”还是“用户已交换” ...？）
• AddressLine1（使用数字可能会造成混乱，第一行是什么-房屋名称，街道名称？）

GoodKeys：使用上述规则

• FinalScore（哦，那个！数据键之一是高分！）
• HttpAddress（可读性更高，术语更清晰）
• CustomerID（因为我们需要一个标识符，而不是对潜意识中的客户的引用）
• UsersExchanged（phe！）
• AddressStreetName（更清楚，我们甚至不需要名称更有意义的数字）