代码可读性的最佳选项卡大小[关闭]答案

【问题标题】：Optimal tab size for code readability [closed]代码可读性的最佳选项卡大小[关闭]
【发布时间】：2009-05-01 01:21:40
【问题描述】：

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

任何人都可以指出文档、研究或合理的论据来确定标签的最佳大小吗？

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

【问题讨论】：

在没有人链接到实际的科学研究来证明某些事情（我会欢迎，但我不确定它是否存在）的情况下，我投票以“主观和争论”来结束这一点。
哦，我喜欢标签大小为 2 ;)
公平地说，许多编程问题都没有确切的答案。我正在寻找最佳实践。你知道？我不希望人们以他们最喜欢的方式回应，我希望有人可以提供一些理由。事实上，克里斯蒂安的回答还不错。我只是在寻找一个前进的标准。也许答案是“它总是主观的”你应该这样回答，如果这是正确的，人们应该投票。
既然 PEP 8 说 4 个空格，那么问题是什么？
这是一个关于缩进宽度的问题，而不是制表符大小（通常是指显示文字制表符的宽度）。

标签： python readability

【解决方案1】：

Four spaces and no hard tabs，如果你是 Pythonista。

【讨论】：

【解决方案2】：

我喜欢 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 个字符长。但它似乎对可读性非常有用。所有代码都在我的余光中，如果我快速扫描，我绝不会错过新代码块的开始。

【讨论】：

+1 用于实际描述您选择的原因。
-1 OP 要求参考客观研究，而不是主观挥手
-1 以 0 个空格开头作为下限，因为 0 个空格在 Python 中不起作用，OP 提到了这一点。

【解决方案3】：

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

【讨论】：

诗没有意义。顺便说一句，你不会遭受名誉损失！
1 个标签用于高效编码

【解决方案4】：

这种讨论经常涉及误解，因为 (as jwz describes) 它通常涉及三个不同的问题：

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

我的回答：

按 Tab 键应该将当前行缩进（或选定的行）一个额外的级别。

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

【讨论】：

【解决方案5】：

过去我使用了 3 个空格。这仍然是我的偏好。但是 4 个空格似乎是 VB 世界的标准。所以我改用 4 以符合我看到的大多数代码示例，以及我团队的其他成员。

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

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

缩进

Use 4 spaces per indentation level.

但Linux kernel CodingStyle 表示不同：

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

本文档还提供了一些示例，说明代码应该是什么样子，以及标识如何改变（虽然它是在 C 中）

【讨论】：

【解决方案8】：

到目前为止还没有人提到这一点，所以我觉得我有义务发布一个。缩进大小的选择（我认为 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 对齐。当每行末尾添加多个 cmets 时，情况会变得更糟。

【讨论】：

【解决方案9】：

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

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

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

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

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

【讨论】：

【解决方案10】：

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

【讨论】：

【解决方案11】：

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

【讨论】：

【解决方案12】：

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

【讨论】：

-1 OP 要求进行客观研究
@MarcMutz-mmutz - 请告诉我，接受的答案中的“客观”是什么。如果你愿意的话，这只不过是一个惯例，一个更大群体的偏好。就像这个一样。

【解决方案13】：

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

【讨论】：

请将 cmets 放在问题下方的 cmets 部分，而不是作为答案。