编写干净的代码并非一件容易的事。它须要用不一样的技巧和不少的实践。写出一手整洁的代码也是开发者们不断追求的目标。函数
让咱们先来看看编写干净代码的一些好处。其中一个主要好处是,干净的代码能够帮助咱们最大限度地缩短阅读和尝试理解代码所需的时间。凌乱的代码会减慢任何开发人员的速度让他的工做很难开展。代码越混乱,开发人员须要了解的时间就越多。并且,若是代码太乱,开发人员可能会思考要不要重构。 学习
1.项目更容易启动和延续
让我在一个简单的例子中证实这一点。假设咱们在很长一段时间后回到了咱们以前作的一个项目。如今,让咱们想象一下,那时候,咱们并无编写最干净的代码,而是相反。在第一次看以后,咱们看到代码有多糟糕和混乱。并且,咱们也已经看到从咱们中断的地方开始是多么困难。
所以,咱们如今必须花费更多的时间在项目上,由于咱们须要了解咱们以前编写的代码。这绝对没有必要。咱们能够从一开始就编写干净的代码来彻底避免它。如今,咱们必须付钱。并且,咱们的旧代码如此混乱或糟糕,以致于咱们可能决定从头开始。听到这些消息后,咱们的客户可能不会高兴。
另外一方面,清洁代码一般没有这个问题。想象一下前面的例子,条件相反。如今,咱们以前的代码干净而优雅。理解它须要多长时间?也许咱们须要阅读代码几分钟才能理解一切是如何工做的。最后,咱们编写它已经有一段时间了。可是,此次投资将明显小于第一种状况。咱们的客户甚至都不会注意到它。
这是代码编写的第一个好处,与咱们将要讨论的技巧一致。并且,这不只适用于咱们本身的项目,也适用于其余开发人员的工做。清洁代码使咱们可以更快地开始。咱们或其余任何人都不须要花费数小时来研究它。相反,咱们能够直接进入工做。 编码
2.更适合新的团队人员入职
编写干净代码的另外一个好处与第一个密切相关。它容许更容易和更快地采用。个人意思是这个。让咱们想象一下,咱们须要聘请另外一位开发人员。她须要多长时间才能理解代码并学习如何使用代码?这取决于。若是咱们的代码很乱而且写得很差,她将须要更多时间来完成它。另外一方面,若是咱们的代码干净,易读,易于理解且简单,她将可以更快地开始。spa
有些人可能会争辩说,这不是一个问题,由于咱们在那里,咱们能够帮助她。并且,这是事实。可是,咱们的帮助应该只须要很短的时间,一两天或三个。可是,它不该该是一周或两三个。最后,咱们决定聘请另外一位开发人员来加快咱们的工做,而不是让它慢下来。咱们的目标是经过帮助她学习使用咱们的代码来消磨更多时间。code
当咱们努力并编写干净的代码时,其余人更容易遵循它并使用它。固然,咱们仍然须要留出一些时间来帮助每一个新开发人员了解和理解咱们的代码。可是,咱们谈论的是几天,而不是几周。此外,干净的代码将帮助咱们为团队带来更多的开发人员,并帮助他们当即理解咱们的代码。简而言之,代码越清晰,解释就越容易,误解就越少。图片
3.更容易理解
咱们须要记住一件事。了解和学习如何使用代码是一回事。可是,这只是一个开始。咱们还须要确保开发人员可以并愿意遵循咱们的编码实践。一样,使用干净的代码更容易实现,而不是凌乱。这很重要,由于咱们不只要编写干净的代码,并且要保持这种方式,不管有多少人使用它。咱们须要长远思考。开发
最后一件事与此有关。若是咱们的某个开发人员决定不遵循当前的编码实践,该怎么办?这个问题一般能够解决。假设咱们有一群人在同一个代码库上工做,一我的开始偏离标准风格。而后,这三件事之一将会发生。首先,该小组的其余成员将推进一位开发人员遵循标准。她会接受它,由于她不想离开。it
第二种选择是开发人员实际上会说服团队的其余成员采用并遵循她的编码实践。若是开发人员提出的编码实践更清晰而且带来更好的结果,这多是一件好事。编写和保持咱们的代码清洁并不意味着咱们应该忽略任何改进它的机会。偏偏相反。我认为,咱们应该始终质疑咱们目前的作法,并寻找这些改进的机会。ast
所以,若是一个开发人员偏离咱们的作法,而且她的作法更好,那么若是咱们作出改变而不是她,可能会更好。我认为在咱们检查和尝试以前,咱们毫不应该忽视某人的作法。老是有改进的余地,咱们应该继续寻找它。最后,还有第三种选择。开发商将决定既不采用咱们的作法也不说服咱们采用她的作法。相反,她可能会定离开团队。class
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.按期检查您的代码
这是我编写干净代码的最后一个提示。简单地编写干净的代码并非一切。咱们的工做不是用最后的分号完成的。下一步是保持咱们的代码清洁。清洁代码须要维护。当咱们写东西时,咱们应该按期检查,清理它并尝试改进它。不然,若是咱们不审查和更新咱们的旧代码,它很快就会过期。就像咱们的设备同样。若是咱们想让它们保持最佳状态,咱们须要按期更新它们。
对于咱们天天使用的代码,状况尤为如此。代码随着时间的推移变得愈来愈复杂和混乱,而不是更简单和更清洁。咱们有责任防止这种状况发生并保持咱们的代码清洁。实现这一目标的惟一方法是按期检查咱们的代码。换句话说,咱们须要维护它。对于咱们再也不关心或没有将来的项目,这可能不是必需的。对于其余人来讲,维护是咱们工做的一部分。
咱们在本文的最后。咱们今天讨论的这六种作法可能不是影响最大或影响最大的那些。可是,它们是经验丰富的开发人员最常提到的那些。这就是我选择它们的缘由。我但愿这些实践或技巧足以帮助您开始编写干净的代码。如今,和全部事情同样,最重要的是开始。因此,选择至少一种作法并尝试一下。
很是感谢您的宝贵时间。有一个美好的一天!