关于程序员:如何写出让同事好维护的代码

留神了,这篇教你如何写出不让共事无奈保护的代码!作者:xybaby,原文:https://www.cnblogs.com/xybab…

写出整洁的代码,是每个程序员的谋求。《clean code》指出,要想写出好的代码,首先得晓得什么是恶浊代码、什么是整洁代码;而后通过大量的刻意练习,能力真正写出整洁的代码。

WTF/min是掂量代码品质的唯一标准,Uncle Bob在书中称蹩脚的代码为沼泽(wading),这只突出了咱们是蹩脚代码的受害者。国内有一个更适宜的词汇:屎山,尽管不是很斯文然而更加主观,程序员既是受害者也是加害者。

对于什么是整洁的代码,书中给出了巨匠们的总结:

  • Bjarne Stroustrup:优雅且高效;含糊其辞;缩小依赖;只做好一件事
  • Grady booch:简略间接
  • Dave thomas:可读,可保护,单元测试
  • Ron Jeffries:不要反复、繁多职责,表达力(Expressiveness)

其中,我最喜爱的是表达力(Expressiveness)这个形容,这个词仿佛道出了好代码的真谛:用简略间接的形式描绘出代码的性能,不多也不少。

命名的艺术

坦率的说,命名是一件艰难的事件,要想出一个恰到好处的命名须要一番功夫,尤其咱们的母语还不是编程语言所通用的英语。不过这一切都是值得了,好的命名让你的代码更直观,更有表达力。

好的命名应该有上面的特色:

货真价实

好的变量名通知你:是什么货色,为什么存在,该怎么应用

如果须要通过正文来解释变量,那么就先得不那么货真价实了。

防止误导

  • 不要挂羊头卖狗肉
  • 不要笼罩习用缩略语

这里不得不吐槽前两天才看到的一份代码,竟然应用了 l 作为变量名;而且,user竟然是一个list(单复数都没学好!!)

有意义的辨别

代码是写给机器执行,也是给人浏览的,所以概念肯定要有区分度。

  • 应用读的进去的单词

如果名称读不进去,那么探讨的时候就会像个傻鸟

  • 使用方便搜寻的命名

名字长短应与其作用域大小绝对应

  • 防止思维映射

比方在代码中写一个temp,那么读者就得每次看到这个单词的时候翻译成其真正的意义

正文

有表达力的代码是无需正文的。

The proper use of comments is to compensate for our failure to express ourself in code.

正文的适当作用在于补救咱们用代码表白用意时遇到的失败,这听起来让人丧气,但事实的确如此。The truth is in the code, 正文只是二手信息,二者的不同步或者不等价是正文的最大问题。

书中给出了一个十分形象的例子来展现:用代码来论述,而非正文

bad
// check to see if the employee is eligible for full benefit
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

good
if (employee.isEligibleForFullBenefits())

因而,当想要增加正文的时候,能够想想是否能够通过批改命名,或者批改函数(代码)的形象层级来展现代码的用意。

当然,也不能因噎废食,书中指出了以下一些状况属于好的正文

  1. 法务信息
  2. 对用意的正文,为什么要这么做
  3. 警示
  4. TODO正文
  5. 放大看似不合理之物的重要性

其中集体最同意的是第2点和第5点,做什么很容易通过命名表白,但为什么要这么做则并不直观,特地波及到专业知识、算法的时候。

另外,有些第一感觉“不那么优雅”的代码,兴许有其非凡违心,那么这样的代码就应该加上正文,阐明为什么要这样,比方为了晋升要害门路的性能,可能会就义局部代码的可读性。7点倡议助您写出优雅的Java代码!这篇也能够看下。

最坏的正文就是过期或者谬误的正文,这对于代码的维护者(兴许就是几个月后的本人)是微小的挫伤,惋惜除了code review,并没有简单易行的办法来保障代码与正文的同步。

函数

函数的繁多职责

一个函数应该只做一件事,这件事应该能通过函数名就能清晰的展现。判断办法很简略:看看函数是否还能再拆出一个函数。

函数要么做什么do_sth, 要么查问什么query_sth。最恶心的就是函数名示意只会query_sth, 但事实上却会do_sth, 这使得函数产生了副作用。比方书中的例子

public class UserValidator {
    private Cryptographer cryptographer;
    public boolean checkPassword(String userName, String password) {
        User user = UserGateway.findByName(userName);
        if (user != User.NULL) {
            String codedPhrase = user.getPhraseEncodedByPassword();
            String phrase = cryptographer.decrypt(codedPhrase, password);
            if ("Valid Password".equals(phrase)) {
                Session.initialize();
                return true;
            }
        }
        return false;
    }
}

函数的形象层级

每个函数一个抽象层次,函数中的语句都要在同一个形象层级,不同的形象层级不能放在一起。比方咱们想把大象放进冰箱,应该是这个样子的:

def pushElephantIntoRefrige():
    openRefrige()
    pushElephant()
    closeRefrige()

函数外面的三句代码在同一个层级(高度)形容了要实现把大象放进冰箱这件事程序相干的三个步骤。显然,pushElephant这个步骤又可能蕴含很多子步骤,然而在pushElephantIntoRefrige这个层级,是无需晓得太多细节的。

当咱们想通过浏览代码的形式来理解一个新的我的项目时,个别都是采取广度优先的策略,自上而下的浏览代码,先理解整体构造,而后再深刻感兴趣的细节。

如果没有对实现细节进行良好的形象(并凝练出一个货真价实的函数),那么阅读者就容易迷失在细节的汪洋里。

某种程度看来,这个跟金字塔原理也很像

每一个层级都是为了论证其上一层级的观点,同时也须要下一层级的反对;同一层级之间的多个论点又须要以某种逻辑关系排序。pushElephantIntoRefrige就是核心论点,须要多个子步骤的反对,同时这些子步骤之间也有逻辑先后顺序。

函数参数

函数的参数越多,组合出的输出状况就愈多,须要的测试用例也就越多,也就越容易出问题。

输入参数相比返回值难以了解,这点深有同感,输入参数切实是很不直观。从函数调用者的角度,一眼就能看出返回值,而很难辨认输入参数。输入参数通常逼迫调用者去查看函数签名,这个切实不敌对。

向函数传入Boolean(书中称之为 Flag Argument)通常不是好主见。尤其是传入True or False后的行为并不是一件事件的两面,而是两件不同的事件时。这很显著违反了函数的繁多职责束缚,解决办法很简略,那就是用两个函数。

Dont repear yourself

在函数这个层级,是最容易、最直观实现复用的,很多IDE也难帮忙咱们讲一段代码重构出一个函数。

不过在实践中,也会呈现这样一种状况:一段代码在多个办法中都有应用,然而又不齐全一样,如果形象成一个通用函数,那么就须要加参数、加if else区别。这样就有点难堪,貌似能够重构,但又不是很完满。

造成上述问题的某种状况是因为,这段代码也违反了繁多职责准则,做了不只一件事件,这才导致不好复用,解决办法是进行办法的细分,能力更好复用。也能够思考template method来解决差别的局部。

测试

十分羞愧的是,在我经验的我的项目中,测试(尤其是单元测试)始终都没有失去足够的器重,也没有试行过TDD。正因为缺失,才更感良好测试的宝贵。

咱们常说,好的代码须要有可读性、可维护性、可扩展性,好的代码、架构须要不停的重构、迭代,但自动化测试是保障这所有的根底,没有高覆盖率的、自动化的单元测试、回归测试,谁都不敢去批改代码,只能任其腐烂。

即便针对外围模块写了单元测试,个别也很随便,认为这只是测试代码,配不上生产代码的位置,认为只有能跑通就行了。这就导致测试代码的可读性、可维护性十分差,而后导致测试代码很难追随生产代码一起更新、演变,最初导致测试代码生效。所以说,脏测试 – 等同于 – 没测试。

因而,测试代码的三要素:可读性,可读性,可读性。

对于测试的准则、准则如下:

  • You are not allowed to write any production code unless it is to make a failing unit test pass. 没有测试之前不要写任何性能代码
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 只编写恰好可能体现一个失败状况的测试代码
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 只编写恰好能通过测试的性能代码

测试的FIRST准则:

  1. 疾速(Fast)测试应该够快,尽量自动化。
  2. 独立(Independent) 测试应该应该独立。不要相互依赖
  3. 可反复(Repeatable) 测试应该在任何环境上都能反复通过。
  4. 自我验证(Self-Validating) 测试应该有bool输入。不要通过查看日志这种低效率形式来判断测试是否通过
  5. 及时(Timely) 测试应该及时编写,在其对应的生产代码之前编写

本文由乐趣区整理发布,转载请注明出处,谢谢。

You may also like...

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据