181

我在 Stack Overflow 和PEP 8上看到，建议仅在 Python 程序中使用空格进行缩进。我能理解一致缩进的必要性，我也感受到了那种痛苦。

首选空间是否存在根本原因？我原以为标签更容易使用。

4

18 回答 18

160

好吧，似乎每个人都对空间有强烈的偏见。我只使用标签。我很清楚为什么。

标签实际上是一个很酷的发明，它出现在空格之后。它允许您在不推动空间数百万次或使用假制表符（产生空格）的情况下缩进。

我真的不明白为什么每个人都在区分标签的使用。这很像老年人歧视年轻人选择更新更高效的技术并抱怨脉冲拨号适用于每部电话，而不仅仅是这些花哨的新手机。“并非每部电话都可以使用音频拨号，这就是它错误的原因”。

您的编辑器无法正确处理选项卡？好吧，找一个现代编辑器。可能是该死的时代，我们现在处于 21 世纪，编辑器是高科技复杂软件的时代早已过去。我们现在有大量的编辑器可供选择，所有的编辑器都支持标签。此外，您可以定义制表符应该有多少，这是您不能用空格做的事情。看不到标签？那是什么辩论？好吧，你也看不到空格！

我可以这么大胆地建议找一个更好的编辑器吗？这些高科技产品之一，大约 10 年前已经发布，显示隐形字符？（讽刺关闭）

使用空格会导致更多的删除和格式化工作。这就是为什么（以及所有其他知道这一点并同意我的人）在 Python 中使用标签的原因。

混合制表符和空格是一个禁忌，也没有任何争论。那是一团糟，永远无法工作。

于 2011-02-19T00:56:16.117 回答
132

答案就在 PEP 中给出[编辑：这段话已在2013 年被编辑]。我引用：

Python最流行的缩进方式是仅使用空格。

您还需要什么其他根本原因？

直截了当地说：还要考虑 PEP 的范围，如第一段所述：

本文档给出了包含主要 Python 发行版中标准库的 Python 代码的编码约定。

目的是使官方 python 发行版中的所有代码格式一致（我希望我们能同意这普遍是一件好事™）。

由于对于单个程序员来说，空格和制表符之间的决定是 a) 真正的品味问题 b) 很容易通过技术手段（编辑器、转换脚本等）处理，因此有一个明确的方法可以结束所有讨论：选择一个.

圭多是可以选择的人。他甚至不必给出理由，但他仍然参考了经验数据。

对于所有其他目的，您可以将此 PEP 作为建议，也可以忽略它——您的选择，或您的团队或您的团队领导。

但是，如果我可以给你一个建议：不要混合使用 ;-) [编辑：混合制表符和空格不再是一种选择。]

于 2008-09-23T15:19:27.373 回答
45

我个人不同意制表符上的空格。对我来说，制表符是文档布局字符/机制，而空格用于内容或在代码情况下命令之间的描述。

我必须同意 Jim 的评论，即选项卡并不是真正的问题，而是人们以及他们想要如何混合选项卡和空格。

也就是说，为了惯例，我强迫自己使用空格。我重视一致性而不是个人偏好。

于 2009-05-16T17:41:35.227 回答
32

选项卡的问题在于它们是不可见的，人们永远无法就选项卡的宽度达成一致。当你混合制表位和空格，并且你在 Python 以外的地方设置制表位（每 8 个空格使用一个制表位），你会看到代码的布局与 Python 看到的不同。而且因为布局决定了块，你会看到不同的逻辑。它会导致细微的错误。

如果你坚持违反 PEP 8 并使用制表符——或者更糟糕的是，混合制表符和空格——至少总是使用“-tt”参数运行 python，这会导致缩进不一致（有时是制表符，有时是相同缩进的空格水平）错误。此外，如果可能，请将您的编辑器设置为以不同方式显示选项卡。但实际上，最好的方法是不要使用制表符，句号。

于 2008-09-23T13:24:26.650 回答
31

空格的原因是制表符是可选的。空格是标点符号中实际的最小公分母。

每个像样的文本编辑器都有一个“用空格替换选项卡”，很多人都使用它。但不总是。

虽然某些文本编辑器可能会用制表符替换一系列空格，但这确实很少见。

底线。空格不会出错。标签可能会出错。所以不要使用制表符并减少出错的风险。

于 2008-09-23T14:45:39.013 回答
30

当您混合制表符和空格时，会出现缩进的主要问题。显然这并没有告诉你应该选择哪一个，但这是推荐一个的好理由，即使你是通过抛硬币来选择它。

但是，恕我直言，有几个小理由偏爱空格而不是制表符：

  • 不同的工具。有时代码会显示在程序员的编辑器之外。例如。发布到新闻组或论坛。在这里，空格通常比制表符做得更好 - 任何地方的空格都会被破坏，制表符也是如此，但反之则不然。

  • 程序员对源代码的看法不同。这是非常主观的 - 它要么是标签的主要好处，要么是根据您所在的一方而避免使用它们的理由。从好的方面来说，开发人员可以使用他们喜欢的缩进查看源代码，因此喜欢 2 个空格缩进的开发人员可以与 8 个空格的开发人员在同一个源代码上工作，并且仍然可以按照他们喜欢的方式查看它。不利的一面是，这会产生影响——有些人喜欢 8-space，因为它给出了非常明显的反馈，表明它们嵌套得太深了——他们可能会看到 2-indenter 签入的代码不断地包裹在他们的编辑器中。让每个开发人员都以相同的方式查看代码会导致行长度和其他问题更加一致。

  • 继续行缩进。有时您想缩进一行以表明它是从前一行携带的。例如。

    def foo():
    x = some_function_with_lots_of_args(foo, bar, baz,
                                        xyzzy, blah)

    如果使用制表符，则没有办法在不混合空格和制表符的情况下为在编辑器中使用不同制表位的人对齐。这有效地扼杀了上述好处。

显然，这是一个深具宗教色彩的问题，编程困扰着它。最重要的问题是我们应该选择一个——即使那不是你喜欢的那个。有时我认为显着缩进的最大优势是至少我们可以避免大括号放置的激烈冲突。

同样值得一读的是Jamie Zawinski 关于这个问题的这篇文章。

于 2008-09-27T17:32:09.227 回答
15

请注意，制表符的使用混淆了 PEP 8 的另一个方面：

将所有行限制为最多 79 个字符。

假设，您使用的制表符宽度为 2，而我使用的制表符宽度为 8。您编写了所有代码，使最长行达到 79 个字符，然后我开始处理您的文件。现在我有难以阅读的代码，因为（正如 PEP 所述）：

大多数工具中的默认包装破坏了代码的视觉结构

如果我们都使用 4 个空格，那总是一样的。任何编辑器可以支持 80 个字符宽度的人都可以轻松阅读代码。注意：80 个字符的限制本身就是一场圣战，所以我们不要从这里开始。

任何非 sucky 编辑器都应该可以选择使用空格，就好像它们是制表符一样（插入和删除），所以这真的不应该是一个有效的论点。

于 2013-08-03T15:49:14.937 回答
9

问题的答案是：PEP-8 想要提出建议，并决定由于空格更受欢迎，因此强烈推荐空格而不是制表符。

PEP-8 注释

PEP-8 说“每个缩进级别使用 4 个空格。”
很明显，这是标准建议。

“对于您不想弄乱的真正旧代码，您可以继续使用 8 空格制表符。”
很明显，在某些情况下可以使用选项卡。

“永远不要混合制表符和空格。”
这是明确禁止混合的——我想我们都同意这一点。Python 可以检测到这一点并且经常窒息。使用 -tt 参数会使这成为一个显式错误。

'Python 最流行的缩进方式是仅使用空格。第二个最流行的方式是仅使用标签。
这清楚地表明两者都被使用。只是要非常清楚：您仍然不应该在同一个文件中混合空格和制表符。

“对于新项目，强烈建议仅使用空格而不是选项卡。”
这是一个明确的建议，也是一个强有力的建议，但不是禁止制表符。

我在 PEP-8 中找不到我自己的问题的好答案。我使用标签，这是我在其他语言中使用过的。Python 接受源代码并排他使用选项卡。这对我来说已经足够了。

我想我会尝试使用空间。在我的编辑器中，我将文件类型配置为专门使用空格，因此如果我按下制表符，它会插入 4 个空格。如果我按 Tab 太多次，我必须删除空格！ 啊！ 删除次数是标签的四倍！我的编辑不能告诉我使用 4 个空格作为缩进（尽管 AN 编辑可能能够做到这一点）并且显然坚持一次删除一个空格。

不能告诉 Python 在读取缩进时将制表符视为 n 个空格吗？如果我们可以就每个缩进 4 个空格和每个制表符 4 个空格达成一致，并允许 Python 接受这一点，那么就不会有问题了。
我们应该找到双赢的解决问题的办法。

于 2008-09-27T16:56:59.090 回答
3

我一直在我的代码中使用制表符。也就是说，我最近找到了使用空格的理由：在我的诺基亚 N900 互联网平板电脑上进行开发时，我现在有一个没有 Tab 键的键盘。这迫使我要么复制和粘贴标签，要么用空格重新编写我的代码。我在其他手机上也遇到过同样的问题。当然，这不是 Python 的标准用法，但需要牢记。

于 2012-01-05T18:31:35.190 回答
2

由于python依赖缩进来识别程序结构，因此需要一种清晰的方式来识别标识。这就是选择空格或制表符的原因。

然而，python 也有一种强烈的哲学，即只有一种方法来做事，因此应该有一个官方推荐一种方法来做缩进。

空格和制表符都对编辑器作为缩进处理提出了独特的挑战。选项卡本身的处理在编辑器甚至用户设置中并不统一。由于空间是不可配置的，它们构成了更合乎逻辑的选择，因为它们保证结果在任何地方看起来都相同。

于 2008-09-23T13:35:42.020 回答
2

JWZ 说得最好：

当 [人们] 阅读代码并完成编写新代码时，他们关心当新范围（或 sexpr 或其他）打开时代码倾向于缩进多少屏幕列......

...我的观点是，解决技术问题的最佳方法是强制 ASCII #9 TAB 字符永远不会出现在磁盘文件中：编程您的编辑器以在将行写入磁盘之前将 TAB 扩展为适当数量的空格。 ..

...这假设您永远不会在它们实际上很重要的地方使用制表符，例如在字符串或字符常量中，但我从不这样做：当它是一个制表符时，我总是使用 '\t' 代替。

于 2008-09-27T17:50:59.740 回答
0

我可以说空格优于制表符的最重要优势是，许多程序员和项目为源代码使用一定数量的列，如果有人提交更改并将其制表位设置为 2 个空格，而项目使用 4 个空格作为tabstop 对于其他人的编辑器窗口来说，长行将太长。我同意标签更容易使用，但我认为空间更容易协作，这对于像 Python 这样的大型开源项目很重要。

于 2008-09-23T13:30:23.233 回答
0

你可以吃你的蛋糕。将您的编辑器设置为自动将选项卡扩展为空格。

（那将是:set expandtab在 Vim 中。）

于 2008-09-23T13:52:25.583 回答
0

我的猜测是大多数 linux 文本编辑器在默认情况下使默认值看起来非常大。我想不出任何其他在制表符上使用空格的好理由。

于 2019-02-26T00:27:26.250 回答
-1

选项卡的普遍问题是它们可以在不同的环境中以不同的方式表示。
在给定的编辑器中，选项卡可能是 8 个空格，也可能是 2 个。
在某些编辑器中，您可以控制这一点，而在其他编辑器中则不能。

选项卡的另一个问题是它们在打印输出中的表示方式。我相信大多数打印机将制表符解释为 8 个空格。

有了空格，毫无疑问。一切都会按照作者的意图排列。

于 2008-09-23T13:25:57.503 回答
-1

除了已经提到的所有其他原因（一致性、从不混合空格和制表符等），我相信还有一些原因需要注意 4 个空格的约定。这些仅适用于 Python（可能还有其他缩进有意义的语言）。根据个人喜好，其他语言的选项卡可能会更好。

  1. 如果编辑器不显示选项卡（这取决于配置，在很多情况下都会发生），另一位作者可能会假设您的代码使用 4 个空格，b/c 几乎所有公开可用的 Python 代码都是如此；如果同一编辑器的制表符宽度恰好为 4，则可能会发生令人讨厌的事情 - 至少，那个可怜的人会因为缩进问题而浪费时间，而这种缩进问题很容易通过遵守约定来避免。所以对我来说，第一个原因是避免一致性的错误。

  2. 重新定义制表符或空格哪个更好的问题，应该问制表符的优点是什么；我看过很多赞美标签的帖子，但很少有令人信服的论据；像 emacs、vi(m)、kate 等优秀的编辑器...根据代码的语义进行适当的缩进——即使没有制表符；相同的编辑器可以很容易地配置为取消缩进退格等。

  3. 有些人在决定代码的外观/布局时有非常强烈的偏好；其他人重视这种自由的一致性。Python 通过规定缩进用于块等，大大降低了这种自由度。这可能被视为一个错误或一个特性，但它有点与选择 Python 相关。就我个人而言，我喜欢这种一致性——当开始在一个新项目上编码时，至少布局与我习惯的接近，所以它相当容易阅读。几乎总是。

  4. 使用空格进行缩进允许有助于理解代码的“布局技巧”；PEP8 中列出了其中的一些示例；例如。

    foo = long_function_name(var_one, var_two,
                         var_three, var_four)

# the same for lists
a_long_list = [1,
               2,
               # ...
               79]

# or dictionaries
a_dict = {"a_key": "a_value",
          "another_key": "another_value"}

    当然，上面的也可以写成

    foo = long_function_name(
    var_one, var_two,
    var_three, var_four)

# the same for lists
a_long_list = [
    1,
    2,
    # ...
    79]

# or dictionaries
a_dict = {
    "a_key": "a_value",
    "another_key": "another_value"}

    然而，后者需要更多的代码行，并且有时认为更少的行更好（b / c你在单个屏幕上获得更多）。但是如果你喜欢对齐，空格（最好由一个好的编辑器辅助）在某种意义上给你在 Python 中比制表符更自由。[好吧，我猜有些编辑器允许您使用制表符执行相同的操作；）-但是使用空格，所有编辑器都可以...]

  5. 回到其他人提出的相同论点 - PEP 8 规定（好的，强烈推荐）空格。如果来到一个只使用选项卡的项目，当然，你别无选择。但由于 PEP 8 约定的建立，几乎所有 Python 程序员都习惯了这种风格。这使得在大多数程序员接受的风格上找到共识变得非常容易……否则让个人就风格达成一致可能会非常困难。

  6. 有助于强制执行风格的工具通常无需额外努力即可了解 PEP 8。这不是一个很好的理由，但让事情开箱即用真是太好了。

于 2013-02-25T21:11:22.847 回答
-1

好吧，我会说 PEP 8 中没有这样的“建议”。它被声明为建议，因为它们不会禁止您编写选项卡，但由于代码必须以最标准化的方式编写，因此我们必须使用空格.

也就是说，如果我是编写标准指南的人，我会推荐制表符，因为它们是一种现代且更实用的代码缩进方式。

最后，我要强调的是，我不鼓励任何人使用制表符，相反，我是说我们所有人都应该使用样式指南中所述的空格。

于 2021-01-14T19:33:53.227 回答
-2

关于Jim 和 Thomas Wouters在评论中的讨论。

问题是......因为制表符和空格的宽度都可以变化 - 并且由于程序员不能就任一宽度达成一致 - 为什么制表符要承担责任。

我同意吉姆的观点——标签本身并不邪恶。但有个问题...

有了空格，我可以控制“我自己的代码” 在世界上每个编辑器中的外观。如果我使用 4 个空格——那么无论您在哪个编辑器中打开我的代码，它与左边距的距离都是相同的。对于标签，我受制于编辑器的标签宽度设置——即使是我自己的代码。我不喜欢那样。

因此，尽管空格确实不能保证一致性——它们至少让你可以更好地控制你的 OWN 代码在任何地方的外观——这是制表符不能做到的。

我认为这不是程序员编写代码的一致性——而是编辑器显示代码的一致性——空格更容易实现（和强加）。

于 2011-08-06T06:53:51.157 回答