写出干净的代码不是一件容易的事。它需要不同的技术和大量的练习。编写干净的代码也是开发者不断追求的目标。编写干净代码的好处项目更容易启动和继续适合新团队成员加入项目团队更容易理解编写干净代码的要点代码更具可读性为变量、函数和方法使用更有意义的名称让每个函数或方法execute使用注释解释任务（重要）以确保一致性定期检查代码编写干净代码的好处让我们首先看一下编写干净代码的一些好处。主要好处之一是干净的代码可以帮助我们最大限度地减少阅读和尝试理解代码所需的时间。混乱的代码会减慢任何开发人员的速度并使他的工作变得困难。代码越乱，开发人员需要花更多的时间来理解。而且，如果代码太乱，开发者可能会考虑重构。1.项目更容易开始和继续让我用一个简单的例子来证明这一点。假设我们在很长一段时间后回到我们早些时候做的一个项目。现在，让我们想象一下，那时我们没有编写最干净的代码，而是恰恰相反。初看之后，我们看到代码是多么糟糕和混乱。而且，我们还看到从中断的地方继续是多么困难。所以我们现在不得不花更多的时间在这个项目上，因为我们需要理解我们之前写的代码。这是绝对没有必要的。我们可以通过从一开始就编写干净的代码来完全避免它。现在，我们必须付钱。此外，我们的旧代码非常混乱或糟糕，以至于我们可能决定从头开始。听到这些消息后，我们的客户可能不高兴。另一方面，干净的代码通常没有这个问题。想象一下前面的例子，条件相反。现在，我们之前的代码干净优雅。需要多长时间才能理解？也许我们需要花几分钟阅读代码才能理解一切是如何工作的。最后，距离我们写它已经有一段时间了。不过，这次的投资会比第一种情况小很多。我们的客户甚至没有注意到它。这是编码的第一个好处，并且与我们将要讨论的技术一致。而且，这不仅适用于我们自己的项目，也适用于其他开发人员的工作。干净的代码使我们能够更快地开始。我们和其他任何人都不需要花费数小时来处理它。相反，我们可以直接开始工作。2.更好地让新团队成员入职编写干净代码的另一个好处与第一个密切相关。它允许更容易和更快的采用。我的意思是这个。假设我们需要雇用另一位开发人员。她需要多长时间才能理解代码并学会如何使用它？这取决于。如果我们的代码乱七八糟，写得不好，她就需要更多的时间来完成。另一方面，如果我们的代码干净、可读、易懂且简单，她就能更快上手。有些人可能会争辩说这不是问题，因为我们在那里，我们可以帮助她。而且，这是真的。但是我们的帮助应该只需要很短的时间，一天或两天或三天。但是，它不应该是一个星期或两个或三个星期。最后，我们决定聘请另一位开发人员来加快我们的工作，而不是放慢速度。我们的目标是通过帮助她学习使用我们的代码来消磨更多时间。当我们努力工作并编写干净的代码时，其他人就更容易遵循和使用它。当然，我们仍然需要留出一些时间来帮助每个新开发人员学习和理解我们的代码。但是，我们说的是几天，而不是几周。此外，干净的代码将帮助我们将更多的开发人员带入团队，并帮助他们立即理解我们的代码。总之，代码越清晰，越容易解释，误解也越少。3.更容易理解我们需要记住一件事。了解和学习如何使用代码是一回事。然而，这仅仅是开始。我们还需要确保开发人员能够并愿意遵循我们的编码实践。同样，使用干净的代码而不是凌乱的代码更容易实现。这很重要，因为我们不仅要编写干净的代码，而且无论有多少人使用它，都要保持这种状态。我们需要从长远考虑。最后一件事与此有关。如果我们的一位开发人员决定不遵循当前的编码实践怎么办？这个问题通常可以解决。假设我们有一群人在同一个代码库上工作，其中一个人开始偏离标准风格。那么，这三件事中的一件就会发生。首先，团队的其他成员将推动开发人员遵循标准。她会接受它，因为她不想离开。第二种选择是开发人员实际上会说服团队的其他成员采用并遵循她的编码实践。如果开发人员提出的编码实践更清晰并带来更好的结果，那可能是一件好事。编写并保持我们的代码干净并不意味着我们应该忽略任何改进它的机会。恰恰相反。我相信我们应该始终质疑我们目前的做法并寻找这些改进的机会。因此，如果开发人员偏离了我们的方法，而她的方法更好，那么我们代替她进行更改可能会更好。我认为在我们检查并尝试之前，我们永远不应该忽视某人正在做的事情。总有改进的余地，我们应该继续寻找它。最后，还有第三种选择。开发商将决定既不做我们做的事，也不说服我们做她做的事。相反，她可能会离开球队。编写干净代码的技巧1.使代码对人可读我们编写的代码确实会被机器解释。然而，这并不意味着我们应该忽视可读性和可理解性。其他人总是有可能触及我们的代码，或者不得不使用它。即使我们让其他人无法访问我们的代码，我们也可能希望在将来重新使用它。因此，以易于理解的方式编写代码符合我们自己的利益。这个怎么样？最简单的方法是使用空格。我们可以在发货前缩小我们的代码。但是，没有必要编写看起来缩小的代码。相反，我们可以使用缩进、换行和空行来使代码结构更具可读性。当我们决定接受这种做法时，我们代码的可读性和可理解性可以得到显着提高。那么，光看我们的代码就足以理解了。让我们看两个简单的例子。//不好的习惯constuserData=[{userId:1,userName:'AnthonyJohnson',memberSince:'08-01-2017',fluentIn:['English','Greek','Russian']},{userId:2,userName:'AliceStevens',memberSince:'02-11-2016',fluentIn:['English','French','German']},{userId:3,userName:'BradleyStark',memberSince:'29-08-2013',fluentIn:['捷克语','英语','波兰语']},{userId:4,userName:'HirohiroMatumoto',memberSince:'08-05-2015',fluentIn:['Chinese','English','German','Japanese']}];//好的做法constuserData=[{userId:1,userName:'AnthonyJohnson',memberSince:'08-01-2017',fluentIn:['English','Greek','Russian']},{userId:2,userName:'AliceStevens',memberSince:'02-11-2016',fluentIn:['English','French','German']},{userId:3,userName:'BradleyStark',memberSince:'29-08-2013',fluentIn:['Czech','English','Polish']},{userId:4个,userName:'HirohiroMatumoto',memberSince:'08-05-2015',fluentIn:['Chinese','English','German','Japanese']}];2.对于变量、函数和方法使用有意义的名字是什么意思？一个有意义的名称是一个具有足够描述性的名称，不仅是我们，其他人也能够理解变量、函数或方法的用途。换句话说，名称本身应该表明变量、函数或方法的用途，或它包含的内容。//Badconstfnm='Tom';constlnm='Hanks'constx=31;constl=lstnm.length;constboo=false;constcurr=true;constsfn='记住名字';constdbl=['1984','1987','1989','1991'].map((i)=>{returni*2;});//BetterconstfirstName='Tom';constlastName='Hanks'constage=31;constlastNameLength=lastName.length;constisComplete=false;constisCurrentlyActive=true;constsongFileName='记住名字';constyearsDoubled=['1984','1987','1989'，'1991']。map((year)=>{returnyear*2;});但是，我们应该记住一些事情。使用描述性名称并不意味着我们可以使用任意多个字符。一个好的经验法则是将名称限制为三个或四个单词。如果我们需要使用四个以上的词，也许我们试图一次做太多事情，我们应该简化我们的代码。所以，让我们只使用必要的字符。3.让一个函数或方法只执行一项任务当我开始编码时，我曾经编写过几乎看起来像瑞士军刀的函数和方法。他们几乎可以处理和做任何事情。这样做的一个后果是通常很难找到一个好名字。其次，除了我，几乎没有人知道这个或那个功能的作用以及如何使用它。好吧，有时甚至我也有问题。所以，我不得不写说明。第三，这些功能有时是不可预测的。我弄得一团糟。然后，有人想出了这个绝妙的建议。让每个函数或方法只执行一项任务。这个简单的建议改变了一切，帮助我编写了干净的代码，至少比以前更干净了。从那一刻起，其他人终于能够看懂我的代码了。或者，他们不需要像以前那样多的时间。我的功能和方法也变得可预测。给定相同的输入，它们总是产生相同的输出。此外，命名也变得更加容易。如果您难以找到函数和方法的描述性名称，或者如果您需要编写冗长的说明以便其他人可以使用它们，请考虑实施这种做法。让每个函数或方法只执行一项任务。如果您的函数和方法看起来和工作起来像一把瑞士军刀，这也可以实现。相信我，这种多功能性并不是优势。这是一个相当不利的因素，随时可能适得其反。4.使用评论进行澄清。有个笑话，开发者最讨厌的事情之一就是自己写评论别人不写评论。无论我们多么努力地为我们的变量、函数和方法想出有意义的名字都没有关系。.我们的代码本身仍然没有达到应有的清晰度和可理解性。还有一些行需要进一步解释。问题可能不在于它们难以理解或使用。相反，为什么我们实现这个或那个函数或方法，或者为什么我们以特定方式创建它可能没有意义。意思是，历史尚不清楚。有时我们可能不得不使用非常规的方法来解决问题，因为其他方法都不起作用，或者我们没有足够的时间想出更好的解决方案。这可能很难用代码解释。通过我们的代码使用注释可以帮助我们做到这一点。评论帮助我们向其他人解释我们为什么要写我们写的东西，以及为什么我们以特定的方式写它。这样一来，其他人就不用猜了。更重要的是，当我们解释原因时，其他人可能会找到更好的方法来解决问题并改进代码。这是可能的，因为他们知道问题是什么以及期望的结果是什么。如果不知道这些信息，其他人就很难创建更好的解决方案。或者，他们甚至可能不会尝试，因为他们认为没有必要。他们可以假设这是我们的意图。因此，每当我们发现自己处于决定使用某种hack、快速修复或非常规方法的情况时，让我们使用注释来解释为什么我们做了我们所做的事情。最好用一两行作为解释性评论，而不是强迫人们猜测。话虽如此，我们应该只在必要的时候使用注释，而不是解释错误的代码。写没完没了的注释行不会帮助我们把写得不好的代码变成干净的代码。如果代码不好，我们应该通过改进代码来解决问题，而不是通过添加如何使用它的说明来解决问题。清除代码优先于使用快捷方式。5.保持一致当我们发现一种特定的编码习惯或我们喜欢的风格时，我们应该坚持并在任何地方使用它。在不同的项目中使用不同的编码实践或风格并不是一个好主意。它几乎和不使用任何编码实践或风格一样有用和有用。回到我们的旧代码不会像它应该的那样顺利和自然。我们仍然需要一些时间来了解我们在这个项目中使用的编码实践，然后才能使用它。最好的办法是选择一套编码实践，并在所有项目中坚持使用它们。然后回到我们的旧代码并继续我们破坏或改进它的地方会更容易。来个实验怎么样？尝试新的编码实践是一件好事。它帮助我们找到更好的工作方式。但是，最好在不同的实验项目或练习中尝试不同的做法，而不是我们的主要项目。另外，当我们决定做一些实验时，我们应该多次尝试这种做法并尝试多个示例。我们应该花时间彻底地做这个实验。只有当我们确定我们喜欢它并且我们对它感到满意时，我们才应该实施它。而且，当我们决定这样做时，最好在我们所有的项目中在全球范围内实施我们的新实践。是的，这需要时间，但它迫使我们正确思考变化。6.定期检查你的代码这是我编写干净代码的最后一个技巧。简单地编写干净的代码并不是一切。最后的分号还没有完成我们的工作。下一步是保持我们的代码干净。干净的代码需要维护。当我们写东西时，我们应该定期检查它，清理它并尝试改进它。否则，如果我们不审查和更新我们的旧代码，它很快就会过时。就像我们的设备一样。如果我们想让它们保持最佳状态，我们需要定期更新它们。对于我们每天使用的代码来说尤其如此。随着时间的推移，代码变得更加复杂和混乱，而不是变得更加简单和清晰。我们有责任防止这种情况发生并保持我们的代码干净。实现这一目标的唯一方法是定期审查我们的代码。换句话说，我们需要维护它。对于我们不再关心或没有未来的项目，这可能没有必要。对于其他人来说，维护是我们工作的一部分。写在最后我们在本文的结尾。我们今天讨论的六种做法可能不是影响最大或最大的。但是，它们是经验丰富的开发人员最常提到的。这就是我选择他们的原因。我希望这些实践或技巧足以让您开始编写干净的代码。现在，与所有事情一样，最重要的是开始。因此，至少选择一种做法并尝试一下。非常感谢您的参与。祝你有美好的一天！
