后端开发教程 - Java、Spring Boot 实战 - msg200.com
干净代码应用于 JavaScript — 第二部分：变量
这篇文章是一系列有趣文章中的第二篇，将深入探讨应用于 JavaScript 的著名主题“干净代码”。
在本系列中，我们将讨论有关干净代码的经典技巧，每个程序员都应该知道，但应用于特定的 JavaScript/TypeScript 语言。
介绍
在这篇文章中，我们将介绍生成干净代码的基本技巧和建议，重点关注编程时最基本的元素：变量。
我们所有的示例都用 JavaScript 来演示，但这些良好实践应该适用于任何编程语言，包括“最接近金属”的编程语言。我之所以这么说，是因为我曾与一些使用 C 或 Go 等语言的同事讨论过，他们不喜欢应用这些实践，并认为在他们的编程语言中“没有人”这样做。然后，我总是回答说，只要是为了改进，就必须有人先打破常规。然而，这条评论促成了同事之间长时间愉快的对话，讨论这些实践的优缺点。
因此，我们从生成专门应用于变量的良好代码的技巧开始。
使用揭示意图的名称
变量名必须能够体现变量的用途。也就是说，除非我们开发的是数学软件，否则不应该使用像“x”或“y”这样的变量名。在数学领域，这些名称是准确的，但如果变量中存储的是其他信息，则应该使用其他名称，因为变量本身必须能够体现你的意图。
在第一种情况下，如果我们调用一个名为 x 的变量，我们如何知道它里面存储了什么信息？根本无法知道！
在第二种情况下，我们继续保留变量名，不透露其意图，并添加注释。为什么要给一个糟糕的变量名添加注释呢？解决方案其实很简单，就是给变量起一个合适的名字。
现在到了有趣的地方，父母要花多长时间才能给孩子起名字？嗯，找到合适的名字会花很长时间，但最棒的是，在 IDE 的支持下，我们可以不断地重命名变量，直到找到更合适的名字。
const x; // What it is?!
const x; // User information
const user;
使用可发音的名称
如果变量名必须体现某种意图，我们就必须能够读出它的名字。如果我们回顾代码整洁之道的主要实践之一，即生成易于理解的代码，那么我们必须认为能够读出变量的名字至关重要。因此，你不应该为特定场合发明缩写词，即使它们看起来是宇宙中最可爱、最巧妙的。你正在与同事一起编程，也是为了你不那么巧妙的未来。
选择变量名称时的另一个错误做法是通过从单词中删除字母来使用小写字母。首先，请记住，我们是用英语编写代码的，而且并非所有开发人员都是英语使用者。因此，我们为什么要将其名称缩短 3 或 4 个字符呢？这样做有什么好处？代码可以通过工具（包括其他语言的编译器在内的转译器）进行操作，代码会被正确地制表（使用 Prettier）。因此，使用难以发音的名称只会让我们费力地推断变量的意图。
请不要让我思考那些不属于我的商业逻辑重点的事情！！
看看下面的代码，你就能完美地推断出这个类正在建模什么类型的数据，但这需要开发团队编写伪代码，甚至需要一些脑力劳动。接下来，阅读第二段代码，它建模了相同的信息，但不需要脑力劳动就能知道存储的是什么类型的数据。
class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
}
class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;
}
不要在名称中使用变量的类型
一种旧的做法是在变量名称中使用前缀来指定数据类型。让我们反思一下：
-
我们是否必须为变量中包含的数据类型创建伪前缀代码？
-
每个公司都有自己的伪代码，我应该按公司还是按项目学习伪代码？
-
如果我在变量名称中使用编程语言的类型系统，为什么还需要它呢？
-
如果我必须将数据类型从数组修改为集合或映射，会发生什么情况？
-
这个前缀代表什么？它能发音吗？
如果我们有一种类型化的语言，为什么我们需要这个前缀呢？即使这种语言不像 JavaScript 那样类型化，我们也需要在变量名中揭示具体的实现，而这将我们与数据类型耦合起来。
也就是说，我们将数据类型或数据结构与要解决的业务的逻辑概念或问题耦合在一起。
这没有任何贡献！！
相反，它会导致变量无法发音，如果我们进行改进（将代码适配到新类型的数据），就必须重命名所有代码。也就是说，这个前缀是 noise。
看一下变量定义中的两个示例。作为开发人员，是否真的有必要使用前缀才能理解变量的内容？
const aCountries = []
const sName = ‘’
const dAmount = 3.2;
const countries = []
const name = ‘’
const amount = 3.2;
对同一变量类型使用相同的词汇
这条建议不仅适用于团队合作，即使是单独编写代码也适用。尤其是在我们软件开发人员职业生涯的初期。
对同一类型的数据使用相同的词汇。也就是说，如果我们需要检索用户或客户的信息。我们不能用不同的方式指代用户或客户，也就是说，有时我们称之为“用户”，有时又称之为“客户”，甚至有时称之为“客户”。更严重的是，我们甚至在变量名后面添加了后缀。
因此，所有软件中要使用的词汇都必须定义。当我们作为一个团队工作时，这个定义尤为重要。不能出现一组开发人员用不同的名称来指代同一个概念的情况。
下面的例子就说明了这一点：同一个概念，却有三种不同的定义。必须始终使用相同的名称，无论是用户、客户还是客户端，但必须始终相同。
getUserInfo();
getClientData();
getCustomerRecord();
getUser();
不要添加不必要的上下文
在变量名称的定义中不需要添加类或包的上下文。
通常会在变量名称中添加 context，以便了解该变量位于哪个工作区。其实没有必要，事实上，当你阅读代码时你很快就会意识到这一点，因为你会发现不必要的冗余会在理解概念时造成干扰。
在下面的例子中，我们定义了一辆汽车，它有三个基本属性和一个方法。在包含上下文的情况下，我们可以观察到“car”这个词是如何不断重复出现的，并且没有任何贡献。如果我们删除“car”这个词（上下文），代码就能完全理解；事实上，由于我们消除了不必要的干扰，代码更容易理解。
const Car = {
carMake: ‘Honda’,
carModel: ‘Accord’,
carColor: ‘Blue’
};
function paintCar(car) {
car.carColor = ‘Red’;
}
const Car = {
make: ‘Honda’,
model: ‘Accord’,
color: ‘Blue’
};
function paint(car) {
car.color = ‘Red’;
}
不要使用魔法数字和字符串
编写代码时，绝对不应该在源代码（硬编码）中写入具有值的数字和文本字符串。这些被称为魔法数字或魔法链。这些数字是什么意思？我需要解读它吗？你意识到了吗，这让我不得不重新思考业务逻辑之外的问题。
因此，这些魔法数字或链必须频繁地存储在常量中，这些常量接收一个指定该魔法数字意向性的名称。
因此，请记住，如果在变量或常量中没有给定名称，则写入在业务逻辑级别有意义的数字或文本字符串会产生噪音。
以下示例展示了如何通过对数字的赋值来思考该数字的含义。此外，如果将“*Administrator *”错误地写成了“*Adminitrator *”，那么文本字符串就很危险，软件将无法正常工作，且无法得知原因。
// What the heck is 86400000 for?
setTimeout(blastOff, 86400000);
user.rol = “Administrator”;
const MILLISECONDS_IN_A_DAY = 86400000;
const ADMINISTRATOR_ROL = “Administrator”;
setTimeout(blastOff, MILLISECONDS_IN_A_DAY);
user.rol = ADMINISTRATOR_ROL;
结论
在我们刚开始成为开发人员时，我们不会注意到变量的名称，因为通常我们一开始只是独自开发脚本或代码。我们的第一个应用程序是为了学习如何编程，一旦开发完成，我们就再也不会回头去看它们了。因此，我们不需要阅读自己的源代码。
然而，当我们开发的软件应用程序需要长期维护，或者需要多个开发人员共同开发时，我们就需要反复阅读源代码。这时，我们赋予变量的名称将赋予我们高质量且简洁的代码。
在本文中，我们回顾了选择变量名称时的一些基本要点。如果你正在学习编程，请把它们写下来，因为它们会为你节省大量的脑力劳动。如果你拥有丰富的职业生涯，你会发现，通过不断阅读代码，你自然而然地得出了这些结论。
请记住，我们已经讨论过以下几点：
-
使用揭示意图的名称
-
使用可发音的名称
-
不要在名称中使用变量的类型
-
对同一变量类型使用相同的词汇
-
不要添加不必要的上下文
-
不要使用魔法数字和字符串