为什么我要垂直对齐代码(你也要如此!)

本文是翻译,版权归原作者所有



上周在 HackerNews,关于 Linux Kernel 代码风格展开了有趣的讨论

在讨论中,我就应不应该垂直对齐代码发起了一场小小的圣战。我完全支持!让我细说端详。

什么是垂直对齐?

举个小例子:

int robert_age = 32;
int annalouise_age = 25;
int bob_age = 250;
int dorothy_age = 56;

下面的代码更易于阅读:

int robert_age     = 32;
int annalouise_age = 25;
int bob_age        = 250;
int dorothy_age    = 56;

我扫一眼就能看到”bob_age”有点儿不正常。我不用多费事,就轻松地看出来它们都是整数。

这条意见还没被广为分享,因此我打算解释一下,为什么很多认为这是一种有用的风格指南。

理解

90% 的编程工作是为了解决问题,剩下的 10% 的工作需要再用 90% 的时间用来理解问题是怎样被解决的。【注1】

阅读代码和阅读散文,有着极大的不同。我们期望作者能够清晰地解释他们的语句,而不是用他们选中的语言过于冗长地说些不相干的东东,我们都期待普通的语法风格。

的确,Kernel 代码风格着重强调了这一点。你选择变量命名的方式,和代码的用途一样重要。

考虑下面的代码:

var thinG=doIt(thestuff,MORE_sTuff); /* LOL! */

即便你对代码库有深入理解,它也不是特别易读的代码行。

var totalBill = apply_tax(initialBill, taxRate);

对于清晰的应用程序,要借助命名习惯、间隔和大写,从而让代码更易于阅读。这意味着,接手我们代码的可怜家伙,将用更少的时间来解密代码,把更多时间放在理解上面。

为什么使用等宽字体?

在所有著名的、老生常谈的舌战中,有两个实力基本相当的阵营,即 等宽字体 【注2】VS 比例字体【注3】 的争论。

某些异教徒会对你说,比例字体最棒的——无视这些异教徒吧。另一些异教徒则在他们争论比例字体所具有的上等纯洁度时,给你的心灵留下了不和谐——这些可怜的、受谴责的灵魂呀。

最终,还要归结到可读性。你觉得,什么东西能够最容易地帮助你理解代码?为什么 IDE 有着色方案——因此你能一眼看出“foo”是函数、常量、变量还是注释。只要能让你更快地理解这段代码的用途,它就是好的东西

这也是电子表格如此受欢迎的原因之一。列提高了可读性。你可以快速地顺着一列扫视,并能注意到某行和其它行是否存在明显不同。

我们没有工具

有趣的是,在 HackerNews 上的讨论中,我面临的最大批评与垂直对齐是否有用无关,而是我们的工具有多么糟糕。

「这破坏了 diff 的可读性和可用性。比如你修改了某个常量,需要快速追踪因此引起的严重 bug。对于水平排列的代码,diff 或许包含了所有修改过的行,从而掩盖了关键修改。有一些忽视空格的变通方案,以及基于单词的 diff,不过依本人愚见,不值得这么麻烦。 ------[Andreas van Cranenburgh](https://news.ycombinator.com/item?id=8662938)

……还有……

假如你有 50 行赋值语句,你把所有值都和最大的那个对齐了,那么增加一个赋值语句,将迫使你更新 50 行代码。我已经遇到过这些情形了,每当那时候,我就明白了,不要那样对齐值 是多么地重要。 ------[scrollaway](https://news.ycombinator.com/item?id=8665741)

这些论点在某些语境中是合理的,但是说明了需要更好的工具。

我想起了 Elastic Tabstops ——自动排列代码块的方法。

[caption id=”attachment_2781” align=”alignnone” width=”393”]Elastic Tabstops By Nick Gravgaard[/caption]

工具能够轻松容纳这种工作方式。计算机就是为我们做单调、重复工作的,CPU 周期「浪费」在让代码更可读方面的代价,已经足够便宜了。

Linux Kernel 中,还有大量例子,垂直排列让代码更便于人类分析。

垂直排列不适用于每个场景,但是对于快速评估代码,其可读性是无与伦比的。

代码是具有创造性的平台,我们通过这个平台来表达想法。如果工具增加了理解这些想法的难度,那么,需要改变的就是工具、而非我们。

注释

译文:为什么我要垂直对齐代码(你也要如此!) 》| 腊八粥