编写良好的方法和变量名称

名字意味着什么？

在面向对象编程中，编写只执行一项主要功能的方法被认为是一种良好实践。为了确保方法遵循此实践，你可以使用一种策略，即编写能够描述方法功能的方法名称。Robert C. Martin 的《代码整洁之道》分享了以下古老而合理的建议：“函数应该只做一件事。它们应该做好这件事。它们应该只做这件事。”

有时很难判断一个方法是否只做一件事；这时我就会参考它的名称。我能写一个不使用“and”或“or”的描述性名称吗？如果答案是否定的，那么这个方法可能包含多个操作；如果答案是肯定的，则表示我的命名是安全的（或者我的命名不够描述）。方法名称很长也没关系——Martin 说过：“一个描述性强的长名称比一个神秘难懂的短名称好。” 使用类似的措辞来描述所采取的操作或抽象概念也是一种很好的惯例，例如，获取值时使用 get，设置值时使用 set，向文件写入数据时使用 write。

以下是一些好的描述性方法名称的示例：

• 写入订单Xml文件（）
• 创建新客户()
• 创建重复的发货联系人列表（）
• 获取不在Salesforce中的零件产品列表（）
• 创建新零件产品（）

无论你做什么，都不要犯这样的错误：一开始就用 DoStuff() 这样的方法名，然后忘记回头更新它！如果你想不出一个描述性的名称，你只需要先进行一些概念化。

不要害怕使用多个词语来表达你的观点，因为描述性的名称可以替代冗长的描述性注释（而且如果方法发生变化，也不需要额外的文档更新！）。你以及你之后的开发者在查看每个方法之前，都应该清楚地知道它的作用。一旦他们开始使用该方法，它应该能够完成所有他们根据名称所预期的功能。

类名和变量名不一定要太长，但它们对于清晰度和可读性同样重要。这些名称应该是名词，例如 Customer() 或 ShippedPartProduct()，以及字符串 partIdCSV 或 int customerAge。我通常会选择使用更长的列表和数组名称，以便更好地描述它们所包含的数据集，例如 partProductsRetrievedFromSalesforce 或 itemIdsFromThisShipment。

不可接受的变量和类名：

• int x = 42;
• bool trueFalse = false;
• var 对象 = “xyz”;
• 辅助类（）
• 我的字符串；

帮助策略

我已经制定了一些策略，这些策略既可以帮助我进行良好的命名，又可以确保我的方法都很简短并且只执行一项主要功能。

第一个策略看起来似乎很简单，但我花了一段时间才真正弄明白：

在对整段代码感到满意之前，不要将代码分解成新的方法。
通过等到完成一段或几段代码后再分解代码，你可以让自己在继续下一件事之前，基本上完成你的思考过程。就像你在写完初稿后可能会改进一篇文章一样，你可以把你的想法提出来，并将它们改进成更合适的句子和段落（例如方法），然后再将其发布出去。你还可以让自己看到全局，这意味着你有机会看到最佳拆分位置，而不是在研究如何解决问题时试图概念化拆分。

通常，我会从一个方法开始，并根据其功能命名。我会在这个方法中编写所有支持代码，即使这些代码并非其工作的一部分，然后运行测试等等。一旦我对结果满意，我会查看我编写的每一部分代码，并将其分解成小块的方法部分。这些部分要么由我编写它们的方法调用，要么我会将它们移到我最初编写代码的方法之前或之后的位置调用。然后，我会再次运行测试，以确保这些更改不会意外破坏任何功能。

考虑您是否有多个相似的数据源。
您是否在应用程序中使用数据库和另一个数据源（例如 Salesforce）？我喜欢在变量中指示数据源，因为我经常会使用 Item 表中的 ItemID 以及 Salesforce 对象中的 ItemID。这两个变量的值可能非常不同，因此保持它们的一致性非常重要。我当前代码库中的一个很好的例子是 partProductSerialNumbersFromSalesforce 和 partProductSerialNumbersFromDB。这些列表将包含两组可能相同的不同存储值 - 我比较它们以确定我们数据库中的特定部分是否已存在于 Salesforce 中，以避免创建重复项。

我不知道这种策略是否是最佳实践，但如果担心出现任何歧义，我偶尔也会包含实际的表或存储过程名称。例如，一个应用程序更新两个相似的表（假设为 Shipments 和 ShipmentLines）；这两个表都有一个必须更新的 UserDef 字段，并且您希望避免在何时更新哪个表时产生歧义。UpdateShipmentTableUserDef() 和 UpdateShipmentLinesUserDef() 似乎是更新这些字段的方法的合理且清晰的名称。显然，对于大多数数据库更新来说，这过于冗长且没有必要，但我认为在像示例中这样的特殊情况下，它确实有帮助。

你的方法会返回值吗？
如果方法会返回值，我会选择使用能够描述返回内容的名称。如果我返回的是逗号分隔的商品 ID 字符串，我可能会选择类似 CommaSeparatedPartProductItemIds(); 的名称；如果我运行的查询返回与某个部件关联的 Salesforce 帐户的 ID，我可能会选择类似 GetPartAccountIdFromSalesforce() 的名称。重要的是要向读者指出预期返回的值。如果他们期望返回的是商品 ID，而返回的是客户名称，那么他们就很清楚该从哪里开始查找该错误了。

语法课

最近，dev.to 的另一位作者@somedood发表了一篇文章，详细描述了命名语法的细节——主要讲解了何时应该使用驼峰命名法 (camelCase)、帕斯卡命名法 (PascalCase) 或 SCREAMING_CASE。点击此处查看：

基于语法的命名约定

Basti Ortiz ・ 19年5月7日

#初学者 #编程 #javascript

我遗漏了什么吗？

你有什么绝妙的方法，确保你的名字能够讲述你的代码？有什么技巧可以确保你的代码对后来者来说具有良好的可读性？我很想听听你最喜欢的命名规则。

我也想听听你见过的最糟糕的名字。我肯定其中肯定有一些挺搞笑的！