python - 代码可读性的最佳标签大小

Question

除了个人喜好，是否有最佳的标签大小（2 个空格？3 个空格？8 个空格？）以提高代码的可读性？在我从事的不同项目中，人们似乎有截然不同的标准。我似乎无法阅读 2 个空格缩进，但像 Google 这样的公司使用它作为标准。

任何人都可以为标签的最佳大小指出文档、研究或有充分理由的论据吗？

如果我们想具体一点，我主要在 python 中工作。这个问题的目的是为我工作的团队选择一个标准。

score 40 · Accepted Answer

40

如果您是 Pythonista，则四个空格且没有硬制表符。

于 2009-05-01T02:08:08.290 回答

score 13 · Accepted Answer

我喜欢 8 个空格（我知道，对吗？）。它使块的开始/结束非常明显。

至于您的问题，需要进行正式的可用性研究。让我们看看限制：

0 个空格

function test(){
var x = 1;
for (i=0; i<=5; i++){
doSomething();
}
}

没有缩进显然是不好的。你无法分辨任何事情的开始或结束。

19 个空间

function test(){
                   var x = 1;
                   for (i=0; i<=5; i++){
                                      doSomething();
                   }
}

大量缩进显然也很糟糕，因为您无法将代码直观地链接到其父函数或循环（或您拥有的），因为您的周边视觉不会延伸那么远。你的眼睛必须前后晃动太远才能方便阅读。

8个空格

function test(){
        var x = 1;
        for (i=0; i<=5; i++){
                doSomething();
        }
}

我想我决定使用 8 个空格，因为“函数”这个词有 8 个字符长。但它似乎对可读性非常有用。所有代码都在我的余光中，如果我快速扫描，我绝不会错过新代码块的开始。

score 12 · Accepted Answer

2 space 4 busy coder
3 space for heavy if statement using script kiddies 
4 space for those who make real money pressing space 4 times
8 space for the man in ties and suit who doesn't need to code

score 5 · Accepted Answer

这种讨论经常涉及误解，因为（正如 jwz 所描述的）它通常涉及三个不同的问题：

当我Tab在文本编辑器中按下键时会发生什么？
当我要求我的编辑器缩进一行或多行时会发生什么？
当我查看包含 U+0009 水平制表符的文件时会发生什么？

我的回答：

按下该Tab键应将当前行（或选定行）缩进一级。

作为次要选择，我还可以容忍像 Emacs 这样的编辑器使用此键来执行上下文相关的 fix-my-indentation 命令。
如果共识足够强烈，则缩进一行或多行应遵循现行惯例；否则，我非常喜欢每个级别的 4 空格缩进。
U+0009 字符应将后续字符移动到下一个制表位。制表位从第 1 列开始，相隔 8 列，没有例外。

score 4 · Accepted Answer

过去我使用了 3 个空格。这仍然是我的偏好。但是 4 个空格似乎是 VB 世界的标准。所以我已经切换到 4 以与我看到的大多数代码示例以及我团队的其他成员保持一致。

score 3 · Accepted Answer

我不知道有任何研究可以回答你的问题。我不认为这是非主观的，但我个人的偏好是 4 个空格。

score 2 · Accepted Answer

由于您使用的是 Python，因此如前所述，您可以采用 Python 的样式指南 ( PEP 8 ) 建议：

缩进

Use 4 spaces per indentation level.

但是Linux 内核 CodingStyle说的不同：

制表符是 8 个字符，因此缩进也是 8 个字符。有一些异端运动试图使压痕深度为 4（甚至 2！）个字符，这类似于试图将 PI 的值定义为 3。基本原理：压痕背后的整个想法是明确定义一个块控制开始和结束。尤其是当您连续看屏幕 20 个小时时，如果您有较大的压痕，您会发现更容易看到压痕是如何工作的。

该文档还提供了一些示例，说明代码的外观以及标识如何更改（尽管它在 C 中）

score 2 · Accepted Answer

到目前为止还没有人提到这一点，所以我觉得我有义务发布一个。缩进大小的选择（我认为 OP 的意思）不仅会影响代码的缩进方式，还会影响一行中可以容纳多少代码以及它们如何对齐。

开发团队最终需要就线路的长度达成某种协议。我从 80 列开始，直到今天我仍然坚持 80 列。AFAIK，stackoverflow 在源代码降价中也使用了 80 列。

当您使用 8 级缩进，以及嵌套 3 级深度的典型函数时，您的代码将从第 24 列开始。这使我只剩下 56 个字符来编写一行代码。

下面是 VLC 中一些代码在 indent=4 时的样子：

            msg_Dbg( p_libvlc, "Adds %s to the running media player", mrl );
            free( mrl );

            /* send message and get a handle for a reply */
            DBusMessage *reply = dbus_connection_send_with_reply_and_block( conn, msg, -1,
                                                                            &err );
            dbus_message_unref( msg );

这是 indent=8 的样子

                        msg_Dbg( p_libvlc, "Adds %s to the running media player", mrl );
                        free( mrl );


                        /* send message and get a handle for a reply */
                        DBusMessage *reply = dbus_connection_send_with_reply_and_block( conn, msg, -1,
                                                                                        &err );
                        dbus_message_unref( msg );

虽然大缩进使代码更易于阅读，但它也使您在嵌套代码回绕之前编写嵌套代码的空间更小。

将制表符大小保持在 8 非常重要。制表符！= 缩进。虽然将硬制表符作为缩进很容易，但它也会产生非常糟糕的后果。很多人也喜欢对齐他们的代码。所以上面的代码在 tab = 4 的情况下看起来像这样：

            msg_Dbg( p_libvlc, "Adds %s to the running media player", mrl );
            free( mrl );


            /* send message and get a handle for a reply */
            DBusMessage *reply = dbus_connection_send_with_reply_and_block( conn, msg, -1,
                                        &err );
            dbus_message_unref( msg );

你会看到这条线&err不再与conn上面对齐。当每行末尾添加多个注释时，情况会变得更糟。

score 1 · Accepted Answer

制表符优于空格的论点是它允许每个人自定义他们的编辑器以查看他们想要的任何缩进级别。反对制表符的论点是当它们混合制表符和空格时（对于作者而言）很难发现。有时您会想要不缩进到制表位的行，这会导致混合制表符/空格。

使用 2 个空格具有以下优点：可以有更多的嵌套块（如果您也有行限制，这很重要），并且使用双缩进（即 4 个空格）是包装长行的可读性很好的方式。缺点是有时很难判断两行是否在同一个缩进。

使用 8 个空格与 2 个空格有相反的优点和缺点。判断缩进级别很容易，但深度嵌套变得难以管理。许多人会认为后者的缺点是优点（因为它使深度嵌套不太理想）。

4 个空格介于这两个极端之间。

但我个人的看法是，你使用什么级别的缩进没有区别。最重要的是选择一些标准并坚持下去。正如其他人所说，如果您正在编写 python，请遵循 PEP8，如果您正在编写 java，请遵循 Sun 的 java style guide，如果您正在执行 linux kernel hacking，请遵循他们的 style guide。即使使用一个比另一个有一些小的优势，也浪费精力争论选择哪个。做出决定，然后继续进行软件工程中有趣的部分。

score 0 · Accepted Answer

根据一项要求程序员根据缩进估计嵌套级别的研究，我读到 2 个空格实际上是最佳的，但是当被问到时，程序员认为 4 是最佳的。需要引用，但找不到。

score 0 · Accepted Answer

我想我记得Code Complete中有一个关于缩进的部分，引用了一些关于哪个级别的标识使代码最易读的研究，但我现在没有它的副本，所以我无法检查它.

score -1 · Accepted Answer

-1

我一直使用一个制表符作为两个空格。

于 2009-05-01T01:26:17.520 回答

score -3 · Accepted Answer

我想 4 个选项卡空间使代码更具可读性......至少就我的项目工作而言，4 个选项卡空间是最舒适的选择......

python - 代码可读性的最佳标签大小

13 回答 13

Related

Reference