改善代码可读性 5个方法送给你

编程有很大一部分时间是在阅读代码,不仅要阅读自己的代码,而且要阅读别人的代码。因此,可读性良好的代码能够大大提高编程效率。可读性良好的代码往往会让代码架构更好,因为程序员更愿意去修改这部分代码,而且也更容易修改。实践中总结出来的这些改善代码可读性经验,与你共勉。

改善代码可读性 5个方法送给你

重用会多次使用的内容

大多数开发人员都知道 D.R.Y. 是什么意思(避免重复代码)。D.R.Y. 可以帮助你预防代码重复的问题。为什么一个函数要写一遍又一遍呢?你应该只编写一次,然后在需要它的各个位置重复使用它。而且如果你需要更改它的代码,就只需要改动一处位置就可以了,用不着把修改好错误的版本复制粘贴到各个地方。但请注意,D.R.Y. 原则会让你引入复杂性。因为到最后,事物被重用的次数会越来越多。当你开始更改被多次重用的代码时,针对这部分代码编写测试的重要性就会充分体现出来了。

避免针对可读性和可维护性制定通行的解决方案

可重用性、可读性和可维护性彼此之间既是朋友也是敌人。当你开始在自己的代码中践行 D.R.Y. 原则,你就会引入复杂性。当你引入复杂性时,可读性水平可能就会下降了。因此,在构建功能时不要想着先做一个通行的解决方案。从简单入手是最好的!第一次尝试肯定没法做到尽善尽美。

通过多次迭代,你就可以在重用应用程序很多部分的同时,仍然保持不错的可读性和可维护性。

当你在拥有许多开发团队的组织中工作时,你的团队可能会分为内部人员和外部人员(例如自由职业者或顾问)。因此在这种情况下,人们会经常在不同组织之间来回切换。在这些场景中,可读性和可维护性是成功的关键。让那些很可能随时离开团队的人员来制定通行的解决方案,并不是一个明智的选择。在某些情况下,你的确需要通行方案,但这些方案必须做到很容易阅读和维护。

尽可能减小模块、类或组件的大小

在为一款应用程序构建一些新功能时,你可能会在构建前作详细的规划。最佳的解决方案肯定是能拆分成许多较小的模块、类或组件的。你想知道为什么吗?因为小段代码更容易测试和维护。

想象一下,人们在现实中搭建高层建筑时,也是从一个个较小的单元开始拼装而成的,而不是一下子就把整幢大楼都造好,然后设法安装到地基上。当然了,例外也是有的。大多数现代库和框架都分成了一些较小的构造块,而不是打包成单个文件。像 Angular、React 和 Vue 这样的 JavaScript 库和框架都采用了组件的概念。我认为他们的选择并不是无意识的结果。

为你的代码自动化执行一些规则和准则

想要编写出可读和可维护的代码,一方面要关注的是代码的架构,另一方面则要关注代码的样式。我想很多读者都经常会见到关于制表符或空格缩进的讨论。不过这里我不会讨论这个话题。无论你在团队中使用的是哪种方案,请确保所有团队成员都遵守它就行了。最好的解决方案是,尽可能让这些代码样式规则和准则自动化。许多 IDE 都集成了这种功能,或者可以通过插件安装。最简单的一种,也是支持多种语言和代码编辑器的方案是 editorconfig。只要添加一个.editorconfig,就可以应用这些规则。

你可以在这些文件中为你的项目调整许多设置。你也可以指定全局设置方案,或者为特定的语言指定设置。例如:

就算只有你一个人,也要像在多人团队中一样编写代码

最后一点也是非常重要的,那就是永远都像在团队中一样编写便于协作的代码!

我可以想象,从未在团队中编写过代码的开发人员是很难理解这一条原则的。应该试着像在团队中一样编写能方便他人理解的代码。想象一下,这就是说你的代码应该足够清晰明了,让其他人可以轻松理解。不要担心负面反馈!你只要关注那些可以让你的代码对其他人更具可读性的反馈意见就行了。毕竟可读代码与读起来略吃力的代码之间并没有很清晰的界限,不同人会在这个问题上有不同的看法。

文章部分素材来源:InfoQ

展开阅读全文

页面更新:2024-04-13

标签:可读性   制表符   代码   可维护性   复杂性   空格   样式   组件   可读   团队   规则   原则   解决方案   人员   方案

1 2 3 4 5

上滑加载更多 ↓
推荐阅读:
友情链接:
更多:

本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828  

© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号

Top