6个小技巧教你编写干净整洁的代码
编写干净的代码并不是一件容易的事。它需要用不同的技巧和很多的实践。写出一手整洁的代码也是开发者们不断追求的目标。
编写干净代码的好处
项目更容易启动和延续
适合新团队人员加入项目组
更加容易理解
编写干净代码的要点
代码更加易读
为变量，函数和方法使用更有意义的命名
让每个函数或方法只执行一个任务
使用注释进行说明（重要）
保持一致性
定期检查您的代码
编写干净代码的好处
让我们先来看看编写干净代码的一些好处。其中一个主要好处是，干净的代码可以帮助我们最大限度地缩短阅读和尝试理解代码所需的时间。凌乱的代码会减慢任何开发人员的速度让他的工作很难开展。代码越混乱，开发人员需要了解的时间就越多。而且，如果代码太乱，开发人员可能会思考要不要重构。
1.项目更容易启动和延续
让我在一个简单的例子中证明这一点。假设我们在很长一段时间后回到了我们之前做的一个项目。现在，让我们想象一下，那时候，我们并没有编写最干净的代码，而是相反。在第一次看之后，我们看到代码有多糟糕和混乱。而且，我们也已经看到从我们中断的地方开始是多么困难。
因此，我们现在必须花费更多的时间在项目上，因为我们需要了解我们之前编写的代码。这绝对没有必要。我们可以从一开始就编写干净的代码来完全避免它。现在，我们必须付钱。而且，我们的旧代码如此混乱或糟糕，以至于我们可能决定从头开始。听到这些消息后，我们的客户可能不会高兴。
另一方面，清洁代码通常没有这个问题。想象一下前面的例子，条件相反。现在，我们之前的代码干净而优雅。理解它需要多长时间？也许我们需要阅读代码几分钟才能理解一切是如何工作的。最后，我们编写它已经有一段时间了。但是，这次投资将明显小于第一种情况。我们的客户甚至都不会注意到它。
这是代码编写的第一个好处，与我们将要讨论的技巧一致。而且，这不仅适用于我们自己的项目，也适用于其他开发人员的工作。清洁代码使我们能够更快地开始。我们或其他任何人都不需要花费数小时来研究它。相反，我们可以直接进入工作。
2.更适合新的团队人员入职
编写干净代码的另一个好处与第一个密切相关。它允许更容易和更快地采用。我的意思是这个。让我们想象一下，我们需要聘请另一位开发人员。她需要多长时间才能理解代码并学习如何使用代码？这取决于。如果我们的代码很乱并且写得不好，她将需要更多时间来完成它。另一方面，如果我们的代码干净，易读，易于理解且简单，她将能够更快地开始。
有些人可能会争辩说，这不是一个问题，因为我们在那里，我们可以帮助她。而且，这是事实。但是，我们的帮助应该只需要很短的时间，一两天或三个。但是，它不应该是一周或两三个。最后，我们决定聘请另一位开发人员来加快我们的工作，而不是让它慢下来。我们的目标是通过帮助她学习使用我们的代码来消磨更多时间。
当我们努力并编写干净的代码时，其他人更容易遵循它并使用它。当然，我们仍然需要留出一些时间来帮助每个新开发人员了解和理解我们的代码。但是，我们谈论的是几天，而不是几周。此外，干净的代码将帮助我们为团队带来更多的开发人员，并帮助他们立即理解我们的代码。简而言之，代码越清晰，解释就越容易，误解就越少。
3.更容易理解
我们需要记住一件事。了解和学习如何使用代码是一回事。但是，这只是一个开始。我们还需要确保开发人员能够并愿意遵循我们的编码实践。同样，使用干净的代码更容易实现，而不是凌乱。这很重要，因为我们不仅要编写干净的代码，而且要保持这种方式，无论有多少人使用它。我们需要长远思考。
最后一件事与此有关。如果我们的某个开发人员决定不遵循当前的编码实践，该怎么办？这个问题通常可以解决。假设我们有一群人在同一个代码库上工作，一个人开始偏离标准风格。然后，这三件事之一将会发生。首先，该小组的其他成员将推动一位开发人员遵循标准。她会接受它，因为她不想离开。
第二种选择是开发人员实际上会说服团队的其他成员采用并遵循她的编码实践。如果开发人员提出的编码实践更清晰并且带来更好的结果，这可能是一件好事。编写和保持我们的代码清洁并不意味着我们应该忽略任何改进它的机会。恰恰相反。我认为，我们应该始终质疑我们目前的做法，并寻找这些改进的机会。
因此，如果一个开发人员偏离我们的做法，并且她的做法更好，那么如果我们做出改变而不是她，可能会更好。我认为在我们检查和尝试之前，我们绝不应该忽视某人的做法。总是有改进的余地，我们应该继续寻找它。最后，还有第三种选择。开发商将决定既不采用我们的做法也不说服我们采用她的做法。相反，她可能会定离开团队。
编写干净代码的提示
1.使代码对人们可读
确实，我们编写的代码将由机器解释。但是，这并不意味着我们应该忽视其可读性和可理解性。总是有可能另一个人会接触我们的代码，或者必须使用它。即使我们让其他人无法访问我们的代码，我们也可能希望将来再回到它。出于这个原因，以一种易于理解的方式编写代码符合我们自己的利益。怎么样？
最简单的方法是使用空格。我们可以在发货之前缩小我们的代码。但是，没有必要编写看起来像缩小的代码。相反，我们可以使用缩进，换行符和空行来使代码结构更具可读性。当我们决定接受这种做法时，我们的代码的可读性和可理解性可以显着提高。然后，单独查看我们的代码就足以理解它了。我们来看看两个简单的例子。
// 不好的习惯 const userData=[{userId: 1, userName: 'Anthony Johnson', memberSince: '08-01-2017', fluentIn: [ 'English', 'Greek', 'Russian']},{userId: 2, userName: 'Alice Stevens', memberSince: '02-11-2016', fluentIn: [ 'English', 'French', 'German']},{userId: 3, userName: 'Bradley Stark', memberSince: '29-08-2013', fluentIn: [ 'Czech', 'English', 'Polish']},{userId: 4, userName: 'Hirohiro Matumoto', memberSince: '08-05-2015', fluentIn: [ 'Chinese', 'English', 'German', 'Japanese']}]; // 好的做法 const userData = [ { userId: 1, userName: 'Anthony Johnson', memberSince: '08-01-2017', fluentIn: [ 'English', 'Greek', 'Russian' ] }, { userId: 2, userName: 'Alice Stevens', memberSince: '02-11-2016', fluentIn: [ 'English', 'French', 'German' ] }, { userId: 3, userName: 'Bradley Stark', memberSince: '29-08-2013', fluentIn: [ 'Czech', 'English', 'Polish' ] }, { userId: 4, userName: 'Hirohiro Matumoto', memberSince: '08-05-2015', fluentIn: [ 'Chinese', 'English', 'German', 'Japanese' ] } ]; 复制代码2.为变量，函数和方法使用有意义的名称
有意义的是什么意思？有意义的名称是足够描述的名称，其他人，而不仅仅是我们，将能够理解变量，函数或方法的目的。换句话说，名称本身应该建议变量，函数或方法用于什么，或者它包含什么。
// Bad const fnm = ‘Tom’; const lnm = ‘Hanks’ const x = 31; const l = lstnm.length; const boo = false; const curr = true; const sfn = ‘Remember the name’; const dbl = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((i) => { return i * 2; }); // Better const firstName = ‘Tom’; const lastName = ‘Hanks’ const age = 31; const lastNameLength = lastName.length; const isComplete = false; const isCurrentlyActive = true; const songFileName = ‘Remember the name’; const yearsDoubled = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((year) => { return year * 2; }); 复制代码但是，我们应该记住一些事情。使用描述性名称并不意味着我们可以随意使用尽可能多的字符。一个好的经验法则是将名称限制为三个或四个单词。如果我们需要使用超过四个单词，也许我们会尝试一次做太多事情，我们应该简化我们的代码。所以，让我们只使用必要的字符。
3.让一个函数或方法只执行一个任务
当我开始编码时，我曾经写过几乎看起来像瑞士军刀的功能和方法。他们可以处理并做几乎任何事情。其中一个后果是，通常很难找到一个好名字。其次，除了我之外几乎没有人知道这个或那个功能是做什么以及如何使用它。好吧，有时甚至我遇到了问题。所以，我不得不写指令。第三，这些功能有时候是不可预测的。我制造了一团糟。
然后，有人提出了这个很好的建议。让每个函数或方法只执行一个任务。这个简单的建议改变了一切，并帮助我编写干净的代码，至少比之前更干净。从那一刻起，其他人终于能够理解我的代码。或者，他们并不需要他们之前需要的那么多时间。我的功能和方法也变得可以预测。在相同输入的情况下，它们总是产生相同的输出。而且，命名也变得更容易了。
如果您很难找到功能和方法的描述性名称，或者您需要编写冗长的指令以便其他人可以使用它们，请考虑实施此实践。让每个函数或方法只执行一个任务。如果您的功能和方法看起来和像瑞士军刀一样工作，也可以实施这种做法。相信我，这种多功能性不是一个优势。这是一个相当不利的因素，任何时候都可能开始适得其反。
4.使用注释进行说明
有个段子是这么说的开发人员最讨厌的一件事就是自己写注释和别人不写注释
无论我们如何努力为我们的变量，函数和方法提出有意义的名称并不重要。我们的代码本身仍然没有尽可能干净和易于理解。仍有一些行需要进一步解释。问题可能不是他们难以理解或使用。相反，为什么我们实现这个或那个功能或方法或为什么我们以特定的方式创建它可能没有意义。意思是，历史还不清楚。
有时我们可能不得不使用相当非常规的方法来解决问题，因为没有别的方法可行，或者我们没有足够的时间来提出更好的解决方案。这可能很难用代码来解释。通过我们的代码使用注释可以帮助我们解决这个问题。评论可以帮助我们向其他人解释为什么我们写了我们写的东西，以及为什么我们以特定的方式编写它。结果，其他人不必猜测。
更重要的是，当我们解释原因时，其他人可能会找到更好的方法来解决问题并改进代码。这是可能的，因为他们知道问题是什么以及期望的结果是什么。在不知道这些信息的情况下，其他人更难以创建更好的解决方案。或者，他们甚至可能不会尝试，因为他们认为不需要它。他们可以认为这是我们的意图。
因此，每当我们发现自己处于决定使用某种黑客攻击，快速修复或非常规方法的情况时，让我们使用注释来解释我们为什么做了我们所做的事情。最好使用一行或两行作为解释注释，而不是强迫人们猜测。
话虽如此，我们应该只在必要时使用注释，而不是解释错误的代码。编写无穷无尽的注释行不会帮助我们将编写糟糕的代码转换为干净的代码。如果代码不好，我们应该通过改进代码来解决问题，而不是通过添加关于如何使用它的指令来解决问题。清除代码优先于使用快捷方式。
5.保持一致
当我们找到我们喜欢的特定编码实践或风格时，我们应该坚持并随处使用它。在不同的项目中使用不同的编码实践或风格并不是一个好主意。它几乎和不使用任何编码实践或风格一样有用和有用。回到我们的旧代码将不会像它可能那样平滑和自然。我们仍然需要一些时间来理解我们在该项目中使用的编码实践，然后才能使用它。
最好的办法是选择一套编码实践，然后在所有项目中坚持这些实践。然后，返回我们的旧代码将更容易，并继续我们中断或改进它。实验怎么样？尝试新的编码实践是一件好事。它可以帮助我们找到更好的方法来完成我们的工作。但是，最好在不同的实验项目或练习上试验不同的实践，而不是我们的主要项目。
此外，当我们决定做一些实验时，我们应该多次尝试这种做法，并尝试多个例子。我们应该花时间彻底做这个实验。只有当我们确信我们喜欢这种做法并且我们对此感到满意时，我们才应该实施它。而且，当我们决定这样做时，最好在我们的所有项目中全球实施我们的新实践。是的，这需要时间，但这会迫使我们适当地考虑变化。
6.定期检查您的代码
这是我编写干净代码的最后一个提示。简单地编写干净的代码并不是一切。我们的工作不是用最后的分号完成的。下一步是保持我们的代码清洁。清洁代码需要维护。当我们写东西时，我们应该定期检查，清理它并尝试改进它。否则，如果我们不审查和更新我们的旧代码，它很快就会过时。就像我们的设备一样。如果我们想让它们保持最佳状态，我们需要定期更新它们。
对于我们每天使用的代码，情况尤其如此。代码随着时间的推移变得越来越复杂和混乱，而不是更简单和更清洁。我们有责任防止这种情况发生并保持我们的代码清洁。实现这一目标的唯一方法是定期检查我们的代码。换句话说，我们需要维护它。对于我们不再关心或没有未来的项目，这可能不是必需的。对于其他人来说，维护是我们工作的一部分。
关于编写干净代码的想法
我们在本文的最后。我们今天讨论的这六种做法可能不是影响最大或影响最大的那些。但是，它们是经验丰富的开发人员最常提到的那些。这就是我选择它们的原因。我希望这些实践或技巧足以帮助您开始编写干净的代码。现在，和所有事情一样，最重要的是开始。所以，选择至少一种做法并尝试一下。
非常感谢您的宝贵时间。有一个美好的一天！
原文地址：https://juejin.im/post/5b56b019f265da0f7f44a74e