优秀程序员写代码一定会用的 11 条经验!

简介:

这是一篇值得收藏起来,隔三差五就拿来重读的文章!因为作者向你保证,他“遇到的所有糟糕的代码,都是因为没采纳这些实践经验。而任何一段优秀的代码,都采纳了至少部分实践经验。”

还等什么?赶快看看这些经验就是什么吧?

我已经写了20年代码了,在此期间曾与17个团队共事过,使用不同的语言做过数百个项目。

这些项目从最简单的博客网站,到支持每秒3000多次请求的API,还有曾经热卖过的应用。

根据这些经验,再结合我读过的书,我认为编程中最重要的是:可读性。

01

可读性

表面上看来,可读性似乎很主观。不同语言、代码、和团队对于可读性的定义不尽相同。但如果深入本质的话,就会发现代码可读性有一些非常关键的因素。

许多程序员太倾向于计算机了,只要程序能运行就一了百了。尽管是老生常谈,但这种方式完全断绝了人参与的可能性。

最近几个月, 我在努力将这些人为因素提炼成11条写程序的实践经验,专门讨论如何增强可读性并降低复杂度。

我在BaseCode中写过这些详细内容,并将其应用到真实世界的代码片段中。

许多人会认为这些太基础、无关紧要,可以忽视。但我可以向你保证,我遇到的所有糟糕的代码都是因为没采纳这些实践经验。而任何一段优秀的代码都采纳了至少部分实践经验。

02

格式

我们在格式上消耗了太多精力。制表符还是空格,Allman还是K&R。总会有一天,你会意识到格式在编程中并不是最重要的。

选择一种格式,应用到代码中,然后将这个过程自动化。然后就可以重新专注于写代码本身了。

03

死代码

所有注释掉的代码块、未使用的变量和无法到达的的代码都是垃圾。他们就像在对读者说,“我不关心这段代码”。

于是恶性循环开始了。日复一日,死代码最终会埋葬你的代码。这正是经典的破窗效应。

必须要找出并干掉死代码。虽然不需要把精力主要放在这里,但一定要时时留意。

04

嵌套代码

逻辑几乎是一切代码的基础。我们写代码是为了做决策、迭代和计算。一般情况下都会导致分支或嵌套,从而造成嵌套得很深的代码块。

虽然计算机很容易阅读这种代码,但对于人类则是非常大的精神负担。因此,代码会变得复杂、难以阅读。应该通过防御语句、提前返回或使用函数式编程等方式消灭嵌套代码。

05

使用对象

尽管现在是面向对象编程的时代,我们依然使用了过多的原始指令。

长长的参数列表,杂乱的数据,自定义的数组或字典结构等。这些都可以重构成对象。

这样不仅能让数据结构变得正规,还能容纳所有重复的、使用原始数据的重复的逻辑。

06

大型代码块

虽然没有具体的数字,但代码块的长度应该是有限制的。如果你认为你的代码块过大,就应该对其进行识别、重组并重构。

这个简单的过程可以让你确定代码块的上下文和抽象级别,以便正确地找出代码的任务,并将代码重构到更加易于阅读、更简单的代码块中。

07

命名规则

当然,好的命名很困难,但只是因为我们人为增加了难度。有个小技巧在编程的许多方面都能用得上,包括命名,那就是——延后。不要纠结某个东西的命名,继续写代码就好。

就算是用一整句话命名一个变量都没问题,继续写代码就好。我可以保证,当你完成整个功能之后,更好的名字就会浮出水面。

08

删除注释

在我看来这一条至关重要,删了注释我才能把精力放到可读性上。不管我如何解释删除注释的必要性,总会有人跟我抬杠,然后举出一个绝对需要注释的例子。

当然,如果哈勃望远镜要和古老的适配器连接,而后者返回一个意思不明的687,这种情况肯定需要注释来说明。但大多数其他情况下,你应该尽量重写代码使得它不需要注释也能看懂。

09

合理的返回

我们总是选择返回最奇怪的值,特别是对于边界条件的情况。像-1、687或null。然后就得写很多代码来处理这些值。实际上,null的创造者称它为“10亿美元的错误”。

应该努力返回更有意义的值。理想情况下,最好是即使在反面情况下也能让调用者继续执行的值。如果真的是异常情况,那么最好用其他方式来通信,而不是使用null。

10

三的原则

考虑一下数学上的序列。给出数字2并问你,“下一个数字是什么?”可能是3可能是4,但也可能是1或2.1。实际上你没办法知道。然后我提供了序列中的下一个数字2, 4然后问,“下一个是什么?”可能是6,8,也可能是16。

同样,尽管猜对的可能性增加了,但还是不能确定。然后我提供了数列中的第三个数字,2, 4, 16,然后问“下一个是什么?”有了三个数字之后,程序员的大脑很容易看出这是个平方序列,于是确定下一个数字是256。这就是三的原则。

这个例子虽然跟编程没关系,但它告诉我们,我们不应该太早做抽象。三的原则能阻止我们过早消除重复的努力,直到有了足够多的信息后再做出决定。用Sandi Mets的话说,“重复的代价远远低于错误的抽象。”

11

对称性

最后一条实践经验能给所有代码的可读性带来诗一般的润色,那就是对称性。这条来自Kent Beck的《实现模式》一书,书中说到:

代码中的对称性是说,同样的思想在任何地方都使用同样的实现。

不过说起来容易做起来难。对称性体现了编程的创造性。它是许多其他实践的基础:命名、结构、对象、模式等。不同语言之间、不同代码之间和不同团队之间对于对称性的定义都可能不一样。

因此,你需要花上许多年去追求对称性。但是,一旦开始在代码中使用对称性,就会迅速呈现纯粹的形式,代码的形状也会迅速变好。


原文发布时间为:2018-10-10
本文作者:Jason McCreary
本文来自云栖社区合作伙伴“ CDA数据分析师”,了解相关信息可以关注“ CDA数据分析师”。
相关文章
|
6月前
|
设计模式 算法 程序员
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
作为开发者,我们在日常开发过程中,往往会遇到反复修改bug的情况,而且不能一次性把代码写的完美无瑕,其实开发项目是一项复杂而富有挑战性的任务,即使经验丰富的程序员也难以在一次性编写完美无瑕地完成代码,我个人觉得一次性写好代码是不可能完成的事情。虽然在设计之初已经尽力思考全面,并在实际操作中力求精确,但程序员仍然需要花费大量时间和精力来调试和修复Bug。那么本文就来分享程序员需要反复修改Bug的原因,以及在开发中所面临的复杂性与挑战。
170 1
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
|
敏捷开发 前端开发 开发者
想要成为软件开发中的王者,需要明白的 21 条准则
想要成为软件开发中的王者,需要明白的 21 条准则
|
设计模式 新零售 供应链
一文教会你如何写复杂业务代码
这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景,如何在架构和代码层面进行应对,是一个新课题。针对该命题,我进行了比较细致的思考和研究。结合实际的业务场景,我沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家。
28642 1
一文教会你如何写复杂业务代码
|
测试技术
初级软件测试面试题怎么找?提供的这两个地方你肯定用得上
最近几年,随着电子产品和互联网的蓬勃发展,各类科技公司如雨后春笋般出现,而软件公司作为科技类公司中的重要组成部分,在这支互联网大军中也占据了重要一席。因而,负责软件问题质检的软件测试岗位也逐渐成了这几年炙手可热的就业岗位之一。
148 0
|
消息中间件 运维 Dubbo
源码阅读的方法、误区以及三种境界
源码阅读的方法、误区以及三种境界
团队里的妹子让阿粉跟她说说怎样写出好的代码
昨天,团队里的妹子很突然地就让阿粉跟她说说怎么才能写出一手好的代码 阿粉本着负责任的态度,专门写了一篇文章出来,妹子嘛,就是要宠的嘛
|
新零售 移动开发 人工智能
程序员写好技术文章的几点小技巧
去年成为了内网技术分享平台的年度作者,受邀写一篇关于“如何写好文章”的文章。我本身并不喜欢写字,去年写的几篇文章,涉及的话题自带流量,所以阅读量多了一些,谈不上有多擅长。不过还是决定分享一下自己在写文章时用到的一些小技巧,希望对大家有帮助。
程序员写好技术文章的几点小技巧
|
存储 程序员 C++
如果当初学习编程时能有人给我这些忠告该多好
Cecily Carver 是多伦多的一位程序媛,和 Jennie Faber 一起创办了一个游戏制作工作室。她喜欢歌剧、舞蹈和弹钢琴。Cecily 在这篇文章分享她在编程道路上的所感所想,给出很多值得思考的编程箴言以及一些思想误区,比如在你学习编程之前思考一下你的目标、编程不是什么神秘的东西、坚持比方法更重要等,可以让我们在编程路上少走一些弯路,从而有更多的时间学习技术让自己变的越来越强大。
226 0
|
运维 前端开发 Cloud Native
想成为全栈工程师,要做到哪几点?
如何成为一名全栈工程师?需要具备哪些技术积累?成为全栈工程师有哪些好处?希望本文能为期望成为全栈工程师的同学提供一点帮助,和同学们一起分享交流。
想成为全栈工程师,要做到哪几点?
|
供应链 设计模式
一文教会你如何写复杂业务的代码
简单的介绍下业务背景,零售通是给线下小店供货的B2B模式,我们希望通过数字化重构传统供应链渠道,提升供应链效率,为新零售助力。阿里在中间是一个平台角色,提供的是Bsbc中的service的功能。
8326 0