Linux:为什么我要竖向对齐程序代码

June 9, 2015 by scott

讨论的进行中，我的一个回复触发了另外一场关于是否应该竖向对齐代码的口水仗。我坚持我的观点！下面让我来解释一下为什么要竖向对齐。

Table of Contents

举一个简单的例子：

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%的编程活动是为了解决问题。另外90%是用来理解代码是如何解决问题的。

阅读代码跟阅读小说没多大区别。我们希望作者能把他的想法写明白，不需要陈词滥调长篇累牍，但同时要遵守所使用的语言的语法。

事实上，Linux内核编码风格里十分强调这一点。你给变量的命名同它的作用同等重要。

看一下下面的这段代码：

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

就算你是十分解这段代码，你读起它来也十分费劲。

var totalBill = apply_tax(initialBill, taxRate);

通过给予变量有意义的命名，空格，大小写区分，我们能让这段代码更清晰。这意味着接手我们的代码的下一位程序员能更容易的理解它。

关于代码编辑器应该使用monospace字体还是proportional字体的争论，从未停息也不会停息，两派人各有所好。

有些异教徒会告诉你proportional 字体是最好的——忽略这些人吧。

最终是为可读性。什么方法能最简单的帮助我们理解代码？所以IDE才会有代码高亮配色，这样你就能轻松的分辨“foo”究竟是一个函数，是一个变量，是一个常量，还是一个注释。只要是能帮助我们理解代码的东西都是好东西！

有趣的是，我遇到的很多批评的声音不是说代码竖向对齐的好坏，而是批评我的代码编辑器不行。

你这样做会破坏使用diff对比版本差异时的可读性和有效性。比如，本来只是一行是有一个变量有bug，你能为了对齐变量改动了很多行，影响了查看关键修改处。也有能够忽略空格的diff技术，但至少你这样做得不偿失。Andreas van Cranenburgh

…还有…

假如说，你有50行代码要竖向对齐，你把所有的值对对齐距离最远的那一行，而增加一个更大距离的行，你需要修改50行。我就遇到过这样的问题，最终发现这样做是错误的。scrollaway

他们说的是对的——在某些情况下。但关键是他们不会使用更好工具。

我记得Elastic Tabstops提供的一个技巧——如何自动对齐代码块：

正确的工具能轻松的完成这样的任务。计算机就是用来为我们干这些枯燥、重复的事情的-CPU的工作很廉价，我们可以“浪费”CPU的工作来让我们的代码更清晰可读。

在Linux 内核代码中还有大量的例子能说明竖向对齐代码能让代码更适合人类阅读。

竖向对齐代码并不是在所有情况下都适用——但对于大多数情况，它的好处是大大的。

代码是我们表达我们的思想的媒介。如果你的工具使得理解这些思想更困难，那说明工具需要改变，而不是我们。