来一起聊聊代码可读性吧.

前言

对于有经验的程序员, 对于代码的可读性似乎并不能有一致的理解, 最近这段时间也常碰上可读性理解不一致的情况, 就想开篇文聊聊这个话题, 本文不是一篇科普或者说给结论的文章, 你可以就代码可读性在评论中添加自己的理解, 在正文里我仅仅是阐述我自己遇到的一些冲突以及当下我对代码可读性的一个理解

通常如果你刚工作没多久, 如果随手写下了这样的代码

const a = 1
复制代码

你邻桌的有经验的同事估计会指出你这个变量的命名不可读, 因为没有意义, 什么是 a, 为什么 a 是 1?

你可能会觉得困惑, a 有什么不好么? 又或者取一个长长的变量名就一定是可读性高的方式么?

在讨论这些困惑之前, 就单 '可读性' 这三个字我们来试着探讨下

小时候写看图说话, 记得老师长教导我们要写的语句通顺, 条理清晰. 中国古代文学, 尤其是文言文一向已精简著称. 一句 疑似银河落九天 就能体现出大气磅礴的画面感, 三国演义用了这么多字来描写诸葛亮, 然后在陈寿的三国志中仅 96 个字

我记得是 96, 错了别打我.

看图说话, 诗词, 文章, 演义小说, 流传至今的方法, 文本必然是脍炙人口, 经典永流传, 就这一点来说这些内容具有非常好的可读性应该不为过吧?

那么既然中文的可读性可长可短, 可以言简意赅也可以丰富详实.

那代码的可读性就一定只有一个标准了么? 比如:

if(a === '1'){
  return true
} else {
  return false
}

if(a === '1') return true

return a === '1'
复制代码

你觉得哪个可读性更好?

我们毕竟是搞工程的, 就软件工程而言, 强调代码的可读性, 必然是有目的的, 这个目的是什么, 可读性讨论的背景就是什么.

当我们撇开强调代码可读性的目的不谈, 只是站在自己的角度, 以自己的经验技术认知作为背景来讨论什么是可读什么是不可读? 显然是有问题的.

例如上述代码对机器来说都是可读的? 那假如你的讨论对象是一台电脑, 他会觉得这些代码的可读性有区别么? 但如果你的讨论对象是一个已经编写多年代码的程序员, 他又会怎么想? 如果是产品呢, 甚至是一个完全不懂技术的人呢, 他会怎么想?

我想每个人想法都会不一样, 所以单纯讨论代码可读性是一件非常主观的事情. 取决于你自己的而不是客观的标准


const libraryBooksTotalCount = 0

const tuShuGuan_shuJi_zongShu = 0

复制代码

图书馆书籍总数, 如果用英文翻译, 应该不止我写的第一种, 不同人来翻译, 估计答案都不一样, 但如果用拼音, 那只要是中国程序员, 答案都是一样的.

所以和英文命名相比, 拼音的可读性更差么? 如果维护代码的人都是中国人呢? 当我们强调代码可读性是为了更好的理解代码背后的含义的时候, 拼音可读性好, 还是英文可读性好?

如果这些代码并不是为了开发一个图书管理系统, 这个时候拼音可读性好? 还是英文可读性好?

我的理解是, 如果团队明确有这个代码的业务背景知识, 或者你在读代码之前已经充分了解业务背景知识, 这些代码就是围绕图书馆作为业务对象来编写的. 拼音更好. 不容易导致变量的再定义问题. 技术专家和业务专家更能容易达成一致理解

但如果你并不了解这段代码背后的业务背景, tuShuGuan_shuJi_zongShu 也可能是图书馆书记总数. 因为拼音和单词比, 缺乏准确的释义.

因此我理解代码可读性并不是一个简单的客观标准, 而是集合了, 业务背景, 可读性维护目标, 技术规范等一系列因素下影响的综合产物.

或者换句话说, 作为软件工程师, 我们不应该只把代码可读性看成是一种客观的既定的标准或者约束, 而是看成一种工程维护的指标, 赋予这个指标实际的业务价值和技术内涵才是我们正确理解和讨论代码可读性意义所在.

这是个开放话题, 你可以在评论区留下自己的看法 😁