代码整洁之道第2章-有意义的命名

在读完第二章之后, 一直纠结要不要写这篇博客, 原因大抵是因为第二章以至后面的几章都是条目式的, 书中罗列了大量的反例, 告诉我们不要怎样怎样; 如果将这些条目在这里都罗列出来, 那就违背了我的本意, 这样抄书的意义是不大的。 思索良久, 还是决定将这本书进行下去; 我对书中第二章的内容做了总结, 并且也准备跟大家聊几个有意思的话题

内容总结

书中第二章名为"有意义的命名", 主要是讲的对变量, 类, 函数等的命名; 我将书中的条目大体归纳为以下这些方面

• 简明扼要

  既要"简明", 还得"扼要"; 这四个字做起来很难的? 命名既要能表达完整的含义, 又不能太过啰嗦。这个其实对应了书中的好几个条目。要做到这一点前提就是杜绝没有任何意义的命名, 如a、i, 当然作者也说了如果只是在方法内, 比如循环中, 用个i啥的也无所谓; 再然后就是要结合当前的语境进行合理的命名; 最后就看看能不能精简一下啊(其实有的时候挺难的, 能把意思表达清楚, 往往是一个庞大的词组或者短语)。检验方法也很简单, 你看一眼名字就能明白这个是什么意思。

• 没有二义

  不要有歧义, 不要有双关语; 他在那时那地的语境中能表示独一无二的意义; 比如同样名如add方法一个用来新增一条, 一个用来在原始集合中添加新的条目, 作者则建议用insert和append进行区分。

• 拒绝模仿

  不要弄的两个变量或者函数等的命名长得差不多, 对确实是不一样, 但是没仔细看真分不出来, 这样在开发过程中很容易混淆, 运行时就会产生错误

• 一以贯之

  用什么就一直用着就行了, 比如你用get代表获取记录, 就别用fetch了, 这样多好呢;

• 旁征博引

  多看看领域内的命名, 比如你做电商的, SKU, SPU这些就是领域内的名词, 你就用这些就行了, 或者你看到源码里人家经常怎么命名啊, 多借鉴学习一下。

好了, 上面我把书中提到的内容都归纳了一下, 下面聊几个有意思的话题。

一个争论: 用英文还是拼音?

相信不少同学都有过这样的疑问或者争论吧, 我的建议是用英文, 其实用拼音的小伙伴大部分都是因为某个词语找不到合适的英文或者他的英文是专有名词非常难懂, 就比如医疗领域有很多指标啊之类的即使把英文摆在你面前, 你也未必认得; 这种情况用拼音也可以, 但是要确保开发的小伙伴都能明白这个代表的啥意思, 最好建一些字典啊、枚举啊之类的规范领域语言。而我建议用英文的原因是, 有好多业务开发下没有那么多难以识别的专有名词, 即使有也可以将难以识别的用拼音, 但是本身命名更多的是短语, 都用拼音肯定说不过去吧。而且拼音可能会有二义性呢, 比如 一样(yiyang)和异样(yiyang)。

接口前面需要加I吗?

这是我在书中看到的, 作者给出了确切的答复, 就是不要再接口前面加I。感觉作者说的也有道理, 我要提供给你的是功能, 而不是告诉你我提供给你的是接口, 别人需要你的功能也不会管你是接口还是怎么怎么样。我为什么把这一点单独列出来呢? 本来我也没有这个疑问, 后来在接触Mybatis-Plus的时候, 用它的生成器生成代码, 接口类都是I开头的, 曾经我还和同事因为此事争论, 现在想想正如作者说的还是不加I好一点

集合类的变量该怎么命名?

这也是一个有意思的问题, 因为我现在在开发的是和电商有关的系统, 系统中往往会涉及到goods相关的, 其实goods本身是一个单词就是货物的意思, 他并不是复数形式, 如果说本身集合变量用的也是goods, 那循环的时候, 单个变量往往就必须变个名字, 之前为了省事还用过good; 而如果用List后缀来命名呢? 这样就不会存在问题了, 但是用List来命名并不是一个规范的做法; 因为我们要描述的功能或者用途, 而不需要管他的具体代码实现, List带有明显的列表的含义; 书中作者说类似于这样的应该用Group或者bunchOfxxx之类的。

防御性编程不可取, 最起码现在不可取

最后, 唠一下防御性编程这个既无聊又无力的话题, 最早这个名词的出现也不知道了, 只知道在网上都用这种来自嘲或者自我happy了。戏谑着说, 只有防御性编程才能让我们立于不败之地, 玩笑归玩笑, 请大家尽量在没跑路之前还是不要防御性编程, 因为迫害的是我们自己, 当面对成千上万行的代码的时候, 任何之前的模糊性的命名, 都可能成为一个炸弹, 什么时候引爆可能就得看天了。

好了, 以上就是第二章的分享了, 谢谢观看!