代码可读性与命名事物

许多人认为代码的可读性与使用的字母和符号有关。他们相信通过添加、删除或更改这些符号可以使代码更易读。在某种意义上，他们是对的。然而，根本原则是：代码的可读性主要取决于字母和符号如何占据空间。

这意味着两件事：

代码周围应有适量的空白。不多也不少。
一行代码中应有适当的空格来分隔不同部分。不同的操作通常应放在不同的行上。缩进应适当使用以分组代码块。

根据这一原则，实际上是代码的缺失使事物可读。这是生活中的一个普遍原则——例如，如果书中字母和单词之间完全没有空格，就很难阅读。另一方面，在晴朗的夜空中很容易看到月亮，因为有很多清晰的黑色空间不是月亮。同样，当你的代码中有适量的空格时，你可以轻松地看出代码的位置和内容。

例如，这段代码难以阅读：

1

x=1+2;y=3+4;z=x+y;print"hello world";print"z is"+z;if(z>y+x){print"error";}

而通过适当的行内、周围和行间空格，它变得易于阅读：

1
2
3
4
5
6
7
8


x = 1 + 2;
y = 3 + 4;
z = x + y;
print "hello world";
print "z is" + z;
if (z > y + x) {
    print "error";
}

然而，也可能有太多或错误的空格。这段代码也难以阅读：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


    x            =          1+        2;
y = 3            +4;


  z = x    +      y;
print    "hello world"         ;
 print "z is " + z;
if (z  >     y+x)
 {        print "error" ;
        }

代码本身应占据与其含义成比例的空间。

基本上，含义丰富的小符号使代码难以阅读。含义不多的非常长的名称也使代码难以阅读。含义量和占据的空间应密切相关。

例如，这段代码不可读，因为名称太短：

1
2


q = s(j, f, m);
p(q);

这些名称占据的空间相对于它们的含义来说非常少。然而，使用适当大小的名称，代码块的作用变得更加明显：

1
2


quarterly_total = sum(january, february, march);
print(quarterly_total);

另一方面，如果名称相对于它们所代表的含义太长，那么代码再次变得难以阅读：

1
2


quarterly_total_for_company_x_in_2011_as_of_today = add_all_of_these_together_and_return_the_result(january_total_amount, february_total_amount, march_total_amount);
send_to_screen_and_dont_wait_for_user_to_respond(quarterly_total_for_company_x_in_2011_as_of_today);

这一原则同样适用于整个代码块和单个名称。我们可以用单个函数调用替换上面的整个代码块：

1

print_quarterly_total();

这甚至比之前的任何示例都更易读。尽管我们使用的名称——print_quarterly_total——比我们其他事物的名称稍长，但这没关系，因为它代表了比其他代码片段更多的含义。事实上，它甚至比我们的代码块本身更易读。为什么？因为代码块占据了大量空间，但实际上含义很少，而函数为相同的含义占据了更合理的空间。

如果一个代码块占据大量空间但实际上没有太多含义，那么它是重构的好候选。例如，这里有一个处理一些用户输入的代码块：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


x_pressed = false;
y_pressed = false;
if (input == "x") {
    print "You pressed x!";
    x_pressed = true;
}
else if (input == "y") {
    if (not y_pressed) {
        print "You pressed y for the first time!";
        y_pressed = true;
        if (x_pressed) {
            print "You pressed x and then y!";
        }
    }
}

如果那是我们的整个程序，可能足够可读。然而，如果这在许多其他代码中，我们可以这样使其更可读：

1
2
3
4
5
6
7
8


x_pressed = false;
y_pressed = false;
if (input == "x") {
    handle_x(x_pressed);
}
else if (input == "y") {
    handle_y(x_pressed, y_pressed);
}

我们可以通过减少到这样来使其更可读：

1

handle_input(input);

在我们的代码中间阅读“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)不仅会让程序员输入起来烦人，还会导致不可读的代码。

命名事物

一位著名程序员曾说过，命名事物是计算机科学中最难的问题之一。然而，这些可读性原则为我们提供了一些关于如何命名事物的好线索。基本上，变量、函数等的名称应足够长以完全传达它是什么或做什么，但不应太长以至于难以阅读。

思考函数或变量将如何被使用也很重要。一旦我们开始将其放入代码行中，它是否会使这些代码行相对于它们实际具有的含义来说太长？例如，如果你有一个函数只被调用一次，单独在一行上，该行没有其他代码，那么它可以有一个相当长的名称。然而，你将在复杂表达式中频繁使用的函数可能应该有一个短名称（尽管仍然足够长以完全传达它的作用）。

评论摘要

文章评论中讨论了SQL空格风格、代码对齐、注释的使用频率以及命名长度与使用频率和范围的关系。一些评论者分享了个人经验，如使用垂直对齐来提高相似代码行的可读性，以及注释应解释“为什么”而不是“什么”。还讨论了文化背景对代码空格感知的影响，以及变量命名应使用客户语言以方便支持。

代码可读性与命名艺术：空间布局与命名的核心原则

本文深入探讨代码可读性的核心原则，强调空格布局和命名长度对代码理解的重要性，通过具体示例对比好坏代码风格，并提供实用命名建议。

代码可读性与命名事物

命名事物

评论摘要