代码可读性与命名艺术:空间布局与命名的核心原则
代码可读性与命名事物
2011 年 1 月 25 日 by Max Kanat-Alexander
许多人认为代码的可读性与使用的字母和符号有关。他们相信通过增加、删除或更改这些符号可以使代码更易读。在某种意义上是正确的。然而,基本原则是:代码的可读性主要取决于字母和符号如何占用空间。
这意味着两件事:
代码周围应该有适量的空白。不多不少。
一行代码中应该有适当的空间来分隔不同部分。
不同的操作通常应该放在不同的行上。
缩进应该适当使用以分组代码块。
根据这个原则,实际上是代码的缺失使事物可读。这是生活中的一个普遍原则——例如,如果书中字母和单词之间完全没有空格,就很难阅读。另一方面,在晴朗的夜空中很容易看到月亮,因为有很多清晰的黑色空间不是月亮。类似地,当你的代码有适量的空间时,你可以轻松地看出代码的位置和内容。
例如,这段代码很难阅读:
而通过适当的行内、周围和行间间距,它变得易于阅读:
然而,也可能有太多或错误的空格。这段代码也很难阅读:
代码本身应该根据其含义多少来占用空间。
基本上,含义丰富的小符号使代码难以阅读。含义不多的长名称也使代码难以阅读。含义量和占用空间应该密切相关。
例如,这段代码不可读,因为名称太短:
这些名称占用的空间相对于它们的含义来说非常少。然而,使用适当大小的名称,代码块的作用变得更加明显:
另一方面,如果名称相对于它们所代表的含义太长,那么代码又变得难以阅读:
这个原则同样适用于整个代码块和单个名称。我们可以用单个函数调用替换上面的整个代码块:
这比之前的任何例子都更可读。尽管我们使用的名称print_quarterly_total
比我们其他的名称长一些,但这没关系,因为它代表了比其他代码片段更多的含义。事实上,它甚至比我们的代码块本身更可读。为什么?因为代码块占用了很多空间,但实际上含义很少,而函数为相同的含义占用了更合理的空间。
如果一个代码块占用了很多空间但实际上没有太多含义,那么它就是一个重构的好候选。例如,这里有一个处理一些用户输入的代码块:
如果那是我们的整个程序,可能足够可读。然而,如果这在很多其他代码中,我们可以这样使它更可读:
我们可以通过减少到这个来使它更可读:
在我们的代码中间阅读“handle_input”比尝试阅读上面的整个第一个块要容易得多,因为“handle_input”占用了适量的空间,而块占用了太多空间。然而,请注意,如果我们做了类似h(input)
的事情,那将会令人困惑和不可读,因为“h”太短,无法正确告诉我们代码在做什么。另外,handle_this_input_and_figure_out_if_it_is_x_or_y_and_then_do_the_right_thing(input)
不仅会让程序员输入起来烦人,而且会导致不可读的代码。
命名事物
一位著名程序员曾说过,命名事物是计算机科学中最难的问题之一。然而,这些可读性原则为我们如何命名事物提供了一些好线索。基本上,变量、函数等的名称应该足够长,以完全传达它是什么或做什么,但又不能太长以至于难以阅读。
思考函数或变量将如何被使用也很重要。一旦我们开始将它放入代码行中,它是否会使这些代码行对于它们实际具有的含义来说太长?例如,如果你有一个函数只被调用一次,单独在一行上,该行没有其他代码,那么它可以有一个相当长的名称。然而,一个你将在复杂表达式中频繁使用的函数可能应该有一个短的名称(尽管仍然足够长以完全传达它的作用)。
-Max 更多精彩内容 请关注我的个人公众号 公众号(办公 AI 智能小助手)公众号二维码

评论