编写干净的代码并不是一件容易的事情, 这需要尝试不同的技巧和实践.
作为一名开发者, 编写一手干净的代码很重要.
先列举出编写干净代码的一些好处, 再提出 6 个技巧用于编写干净代码, 供开发者进行参考学习.
开头
写干净代码的好处
先来了解编写干净代码的一些好处. 其中一个主要好处是, 干净的代码可以减少花在阅读上的时间和理解代码的时间. 凌乱的代码会减慢任何开发人员的速度, 使开发者的工作变得更加困难. 代码越混乱, 开发人员就越需要花更多的时间去充分理解它, 这样才能使用这些代码. 而且, 如果代码太乱, 开发人员可能会决定停止阅读这些代码, 并自己从头开始编写.
1. 更容易开始和继续一个项目
先用一个简单的例子来说明这个问题. 假设在很长一段时间后我们回到了之前的一个项目, 也许在这段时间是一位客户联系我们去做了另一项工作. 现在, 想象一下, 那时如果没有编写干净的代码, 那么在第一眼看到代码之后, 该是有多糟糕和混乱. 而且, 也可以知道从当初离开的地方开始编码有多困难.
因此, 现在必须花更多的时间在项目上, 因为我们需要理解之前编写的代码. 这本来是可以避免的, 如果从一开始就编写干净的代码, 然而现在必须为此付出代价. 而且, 旧代码是如此混乱和糟糕, 以至于我们可能决定从头开始. 客户听到这些消息后可能不会高兴.
另一方面, 干净的代码通常就没有这个问题. 假设前面的例子是相反的情况, 以前的代码是干净和优雅的, 那么理解它需要多长时间? 也许只需要读几分钟的代码就能理解所有的工作原理, 而且我们可能已经开始编写一段时间了, 所以在这种情况下花的精力将明显小于第一个案例, 同时, 客户也不会太在意.
这是编写干净代码的第一个好处, 而且, 这不仅适用于自己的项目, 也适用于其他开发人员的工作. 干净的代码可以更快地启动工作, 任何人都不需要花费数小时来研究代码, 相反, 我们可以直接进入工作.
2. 有利于团队新员工培训
编写干净代码的另一个好处与第一个好处是密切相关的, 那就是可以让新员工更容易更快地使用代码. 假设我们需要雇佣一个开发人员, 那么她要花多长时间才能理解代码并学会使用它呢? 当然这要视情况而定. 如果我们的代码很乱, 写得很差, 她就需要花更多的时间来学习代码. 另一方面, 如果代码干净, 易读, 简单易懂, 她将能够更快地开始她的工作.
有些人可能会说, 这不是个问题, 因为其他开发人员可以帮助她. 当然这是正确的, 但是帮助只应该花很短的时间, 是两三次或者一两天, 而并不应该是两三个星期. 所以, 决定雇佣另一个开发人员的目的, 是来加速我们的工作, 而不是减慢速度, 也不是花费更多的时间来帮助她学会使用代码.
当我们努力写出干净的代码时, 其他人就会向我们学习, 也就更容易跟着写出干净的代码. 当然, 仍然需要留出一些时间来帮助每个新开发人员了解和理解代码. 当然, 我的意思是几天, 而不是几周. 此外, 干净的代码将帮助团队带来更多的开发人员, 并同时帮助他们理解代码. 简单地说, 代码越简洁就越容易解释, 误解也就越少.
3.更容易遵循编码模式
有一件事需要记住, 理解和学习如何使用代码是一回事. 然而, 这仅仅是个开始, 同时还需要确保开发人员能够愿意遵循我们的编码模式. 当然, 使用干净的代码比混乱的代码更容易实现这个目标. 这是很重要的, 因为团队不仅想要编写干净的代码, 而且还一直保持这种模式, 这也是需要长期思考的.
另外, 如果开发人员不遵循当前的编码模式该怎么办? 这个问题通常可以自行解决. 假设有一群人在同一个代码基础上工作, 其中一个人开始偏离标准样式. 然后, 团队的其他成员将推动这个开发人员遵循标准. 她会接受建议, 因为她不想离开这个团队.
还有一种情况, 开发人员会说服团队的其他人采纳并遵循自己的编码模式. 如果开发人员提出的编码模式更干净, 并且能带来更好的结果, 这当然是件好事. 的确, 编写和保持干净的代码并不意味着应该忽略任何改进它的机会, 我认为应该始终对目前的做法保持可改进的态度, 并努力寻找改进的机会.
因此, 如果一个开发人员偏离了当前的模式, 同时她的模式也更好, 那么我们做出改变也许会更合适. 所以在尝试其他模式之前, 不应该忽视其他人的编码实践, 同时我们应该继续寻找改进的余地. 最后, 第三种情况. 开发人员决定既不采用我们的实践, 也不说服我们采用她的实践. 因为她将决定离开团队.
技巧
现在除了讨论编写干净代码的好处, 也是时候学习一些技巧来帮助我们实现这个目标了. 正如将在以下看到的, 干净的代码包含并遵循着一些方法. 这些方法使代码更干净, 易读, 更易于理解, 更简单. 当然没有必要实施所有的方法, 实施并遵循一两项措施就足以带来积极的结果.
1.编写可读的代码
的确, 所写的代码将会机器解释, 然而这并不意味着应该忽视代码的可读性和可理解性, 因为在将来总会有另一个人会使用我们写的代码. 即使让别人无法访问我们的代码, 但我们自己也可能在将来又重新拾起这些代码. 出于这些原因, 让代码便于阅读和理解是符合我们自己的利益的. 那么如何实现呢?
最简单的方法是使用空格. 在发布代码之前, 可以缩减代码, 但是没有必要让代码看起来很小型化. 相反, 可以使用缩进, 换行和空行来使代码结构更具可读性. 当决定采用这种方式时, 代码的可读性和可理解性就会显著提高. 然后, 看着代码就可以更容易理解它了
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 个单词. 如果需要使用超过 4 个单词, 说明这个函数或方法需要同时执行很多的任务, 所以应该简化代码, 只使用必要的字符.
3. 让一个函数或方法只执行一个任务
当开始编写代码时, 使用的函数和方法看起来就像一把瑞士军刀, 几乎可以处理任何事情, 但是很难找到一个好的命名. 另外, 除了编写者, 几乎没有人知道函数是用来做什么的以及该如何使用它. 有时我就会遇到这些问题, 我在这方面做的很不好.
然后, 有人提出了一个很好的建议: 让每个函数或方法只执行一个任务. 这个简单的建议改变了一切, 帮助我写出了干净的代码, 至少比以前更干净了. 从那以后, 其他人终于能够理解我的代码了, 或者说, 他们不需要像以前一样花很多时间去读懂代码了, 功能和方法也变得更好理解. 在相同的输入下, 总是能产生相同的输出, 而且, 命名也变得容易得多.
如果你很难找到函数和方法的描述性名称, 或者需要编写冗长的指令以便其他人可以使用, 那请考虑这个建议, 让每个函数或方法只执行一个任务. 如果你的功能和方法看起来像瑞士军刀一样无所不能, 那请你执行这个方法, 相信我, 这种多才多艺不是一种优势. 这是一个相当不利的情况, 可能会产生事与愿违的结果.
附注: 这种让每一个函数或方法只执行一项任务的做法被称为保持纯函数. 这种编码实践来自于函数式编程的概念.
4. 更容易遵循编码模式
不管多么努力地为变量, 函数和方法想出有意义的名字, 代码仍然不可能完全清晰易懂, 还有一些思路需要进行解释. 问题可能不是代码很难理解或使用, 相反, 其他人可能不理解为什么要实现这个函数或方法, 或者为什么要以特定的方式创建它. 意思是, 创建函数或方法的意图还不清楚.
有时可能不得不采用非传统的方法来解决问题, 因为没有足够的时间来想出更好的解决方案, 这也很难用代码来解释. 所以, 通过代码注释可以帮助解决这个问题, 也可以帮助我们向其他人解释为什么写了这个方法, 为什么要用这种特定的方式来写, 那么其他人就不必猜测这些方法或函数的用途了.
更重要的是, 当我们使用注来解释代码后, 其他人可能会找到一个更好的方法来解决这个问题并改进代码. 这是有可能的, 因为他们知道问题是什么, 以及期望的结果是什么. 如果不知道这些信息, 其他人就很难创建更好的解决方案, 或者他们可能不会去尝试, 因为他们认为没有必要去修改创建者自己的想法.
因此, 每当自己决定使用一些快速修复或非传统的方法时, 要用注释来解释为什么这么做. 最好是用一两行注释来解释, 而不用别人来猜测.
也就是说, 我们应该只在必要的时候使用注释, 而不是解释糟糕的代码. 编写无穷无尽的注释将无助于将糟糕的代码转换成干净的代码. 如果代码不好, 应该通过改进代码来解决这个问题, 而不是添加一些如何使用它的说明. 编写干净的代码更重要.
5. 保持代码风格一致性
当我们有自己喜欢的特定编码方式或风格时, 就会在任何地方一直使用它. 但在不同的项目中使用不同的编码风格不是一个好主意, 而且也不可能很自然地回到以前的代码, 所以仍然需要一些时间来理解在项目中使用的编码风格.
最好的方法是选择一套编码方式, 然后在所有的项目中坚持使用. 这样的话, 回到之前的旧代码会变得更容易. 当然, 尝试新的编码方式是一件好事, 它可以帮助我们找到更好的方法来开展工作. 但是最好是在不同的实验项目或练习上尝试不同的编码风格, 而不是在主要项目上进行.
另外, 当我们决定做一些试验的时候, 就应该尝试多次练习, 应该花时间彻底地做好. 只有真正确信喜欢这种做法, 并且对它感到满意时, 才应该去实施它. 而且决定这样做的时候, 最好应用在所有的项目中. 是的, 这需要时间, 这也会促使我们正确地思考.
6. 检查你的代码
这是最后一个技巧. 不仅仅是编写干净的代码, 还要完成最后的工作, 那就是需要维护干净代码. 我们应该定期检查代码, 并试着改进它. 否则, 如果不审查和更新我们的旧代码, 它很快就会过时, 就像我们的设备一样. 如果想让代码保持最佳状态, 就需要定期更新它们.
对于每天使用的代码, 情况也是如此. 代码会变得更加复杂和混乱, 所有应该避免这种情况发生, 并保持代码干净. 实现这一点的唯一方法是定期检查我们的代码. 换句话说, 我们需要保持它. 对于那些未来不再关心的项目来说, 这可能是不必要的, 但对其他的来说, 维护代码是工作的一部分.
最后
这六种做法, 可能不是影响最大的, 也可能不是最重要的, 但这些是经验丰富的开发人员最常提到的, 这也就是我选择它们的原因. 我希望这些实践或技巧能够帮助你开始编写干净的代码.
现在, 就像所有的事情一样, 最重要的是开始. 所以, 至少选一个技巧, 然后试一试.
自己是从事了五年的前端工程师, 不少人私下问我, 2019 年前端该怎么学, 方法有没有?
没错, 年初我花了一个多月的时间整理出来的学习资料, 希望能帮助那些想学习前端, 却又不知道怎么开始学习的朋友.
如果你依然在编程的世界里迷茫, 不知道自己的未来规划, 可以加入 web 前端学习交流群: 731771211 里面可以与大神一起交流并走出迷茫. 新手可进群免费领取学习资料, 看看前辈们是如何在编程的世界里傲然前行! 群里不停更新最新的教程和学习方法 (进群送 Web 前端系统学习路线, 详细的前端项目实战教学视频), 有想学习 Web 前端的, 或是转行, 或是大学生, 还有工作中想提升自己能力的, 正在学习的小伙伴欢迎加入
点击: 加入 http://u6.gg/ek2NA
来源: http://www.qdfuns.com/article/51714/2c087b8971bab76d2eefac59985dd102.html