片对空间Python编程

Question

我总是使用标签的压痕，当我做Python编程。但后来我碰到一个问题，在这里所以如果有人指出，大多数Python程序员使用的空间而不是标签，以尽量减少编辑来编辑错误。

这是如何发挥作用？是否还有其他原因为什么一个会使用的空间而不是标签的蟒蛇?或者是根本不真实的吗?

我应该换我的编辑插入空间，而不是标签，或保持在会喜欢我？

Answer 1

因为 PEP-8 告诉我们使用空格。

Answer 2

厌倦了追压痕错别字(8个空间?不，7 9...哎呀)我交换我的消息来源来'的标签。

1tab==1缩水平，完全停止

点是：如果你想要显示的压痕4、8或pi/12字符的宽度，只是改变设置在你的文本编辑器，不要乱的代码。

(就个人而言，我使用4个字符的宽度卡...但是有些人会喜欢3或8个空间，或者甚至使用变宽度的字体。)

Answer 3

这样对主说：你要用四个空格缩进。不多也不少。四是你要缩进的空格数，你的缩进数应为四。八，你不要缩进，也不要缩小你的两个，除非你接着四个。标签正好。 - Georg Brandl

Answer 4

使用显示标签字符的编辑器（所有空白，就此而言）。你是编程，而不是写文章。

我使用标签。选项卡中没有单空间错误的空间（如果可以看到它们）。问题是人们使用不同的编辑器，世界上唯一常见的事情是：tab == indent，如上所述。有些人将tab键设置为错误的空格数，或者手动操作并弄得一团糟。 TAB并使用真正的编辑器。 （这不仅与PEP相反，它也与C / C ++和其他与空白无关的语言有所不同。）

/从肥皂盒下来

Answer 5

我在空格上使用制表符的主要原因是退格键。如果我在一条线上并且我想退格 - 只删除那一行上的缩进，我必须按空格键4x（如果它是空格）;然而，如果它是标签，我只需要打一次。

我会继续使用标签，因为<！>＃8212;就像在<！>＃8212之前所说的那样;从标签转换为空格更容易，但不是相反。

我想我想编写一个简单的程序，将带有空格的代码转换为带有标签的代码，因为我讨厌讨厌的空间。他们把我推到了墙上！

哦！使用箭头键向左和向右导航总是一个痛苦的空间。

更新：Sublime Text 3现在删除带有退格键的完整软选项卡;但是，箭头键导航仍然很乏味。

更新：我现在使用 vscode 并写了 TabSanity扩展，用于解决退格，删除和箭头键导航问题。

Answer 6

最<！>“pythonic <！>”;方法是每个缩进级别使用4个空格。然而，Python解释器将识别空格或制表符。唯一的问题是你绝不能混合空格和标签，选择其中一个。也就是说，规范建议使用空格，大多数开发人员都使用空格，所以除非你有充分的理由不这样做，否则我会说空格。

Answer 7

到目前为止，我可以告诉，这里有的利弊的标签vs的空间。

利弊的标签：

• 较少的按键需要缩进，消缩进和横的压痕。(甚至如果你IDE有一些空间-压痕聪明它将永远不如标签。)
• 不同的程序员可以使用不同的标签尺寸显示器，因为他们的愿望。
• 你永远不可能有光标的"内"的一个缩进符。例如说你们是复制某些线路，与标签，你可以点击含糊地附近开始的一个行为开始选择和你会得到所有第一选项。与空间你可能会错过的第一个空格除非你打的小目标之间的保证金。同样除去的一个缩进行，大多数编辑不要处理紧迫的backspace好，如果你的光标是在中间的四个空间的压痕符。它通常将删除一个空间。与标签工作的预期。
• 一致性的其它语言，这样你就不必设置你的编辑上来使用，例如标签C++/Java和空间蟒蛇。
• 错误的凹痕可能会更显而易见的(即一个额外的标签远大于一个额外的空间)。

弊的标签：

• 最Python程序员使用的空间所以你会对《公约》。
• 使用空间对齐的多行报表更易于使用的标签。你的 可能 使用标签-为压痕，空间为准，但似乎有点冒险在蟒蛇!

有一些非问题被夸大了，通过的一些人：

1. 你可能会得到流浪空间标签的压痕的螺丝的东西:几乎所有Ide/编辑支助的可视化的空白，这几乎为可能你会得到流浪标签空间缩进!我不能看到这是一个常见的错误。此外， 大多数 压痕错误将会被抓到蟒蛇，和良好的IDEs应当能够突出显示不同的压痕。

2. 你不能调整的事情很容易地与标签:这是真实的，如果你要的角色-完美的路线，但是PEP-8的建议对此，蟒蛇不会发挥好多线路的发言。

3. 人们差设置标签尺寸显示在他们的编辑所以你的代码看起来不同，在不同的地方：是啊，那实际上是一个有益特征的标签。

我已经开始了使用空间是一致的，与其他代码，但说实话这是令人沮丧的，我可能会变回标签。这在很大程度上取决于能力的IDE,但以我的经验任何数量的IDE支持空间的压痕是不如只使用标签。

所以除非你 真的 不喜欢，正在不一致 大多数 (推测是不切！) 蟒蛇的代码，使用标签，打开空白的可视化和缩进突出显示(如果有)。最大的原因对于我来说是方便的选择和(相当重要的海事组织)减少键击。一些公约都是愚蠢的。

更新:我们发现，有一个编辑，在整个世界(不包括废话就像Vim)，适当地支持空间的压痕:原子。它有一个选项所谓的"原子tabstops"，使得4个空格的行为，如果它是一个选项在所有方面(除了能够调整它)。可悲的是，原子是一个相当缓慢的和臃肿的编辑，但这是一个伟大的功能和如果你被迫使用的空间，这可能是一个好的选择。希望有一天其他编辑人员将开始给予支持。 这里的问题VSCode.

Answer 8

我最近发现了一篇名为 Python：关于缩进的神话，讨论了这个问题和相关问题。这篇文章有充分的理由在编写Python代码时建议使用空格，但肯定存在分歧的余地。

我相信大多数Python程序员都只使用空格。

Answer 9

使用编辑器，当您按TAB键时，可以向空格键符号插入空格，而不是插入\ t字符。然后忘了它。

Answer 10

你可以混合标签和空格......但是一个标签被认为是与8个空格相同的缩进，所以除非你的编辑器被设置为将标签视为8个空格，否则混合它们时会遇到麻烦

Answer 11

使用空格而不是标签时遇到的唯一不便是您无法轻松删除缩进级别;你必须删除四个空格而不是一个标签。

Answer 12

标签规则。嵌套循环的参数相同，并且您希望将外循环<！>“返回<！>”; 1级。提示：如果要将旧的空间错误的python代码转换为选项卡，请使用TabOut实用程序作为上的可执行文件。 http://www.textpad.com/add-ons/ 。

Answer 13

我非常强烈地认为，无论历史惯例如何，制表符都是更好的选择，并且应该在未来编写的每个Python代码行中替换空格。就像踢出一个无能的暴君一样。我的理由是：作为核心价值的简单。使用两个或四个字符作为一个语义任务？除了传统，IMO没有任何理由。

Answer 14

在文件中混合缩进时，会发生编辑器到编辑器错误。这产生如下：一个代码块用4个空格缩进，然后在<！>“中用一个缩进级别<！>”;它用缩进键缩进。现在做这个的异教徒（混合标签和空格）有它所以他的标签也是4个空格，所以他看不出任何问题，Python看不出任何问题。

现在我们的受害者来了，他的标签设置为8个空格。现在，我们的受害者认为代码看起来全部被破坏，通过删除一级缩进来修复，现在使代码看起来像一样仍然有2个级别的缩进，但真的是一个级别。在这一点上，所有的地狱都破裂了。

这里的教训是，你永远不应该混合标签和空格。如果您坚持这一点，那么无论您个人使用哪种代码，都可以轻松地将代码重新插入空格或制表符。确保不混合制表符和空格的最佳方法是始终使用python运行-tt，这会在制表符和空格混合时产生错误。

对于制表符和空格，我个人使用制表符，使其与外观分开缩进 - 当使用制表符缩进代码时，更改代码的外观要比使用空格更容易。我知道这与99％的Python程序员所做的相反，但那是我的个人偏好，并且在任何情况下都很容易将选项卡式文件转换为间隔文件。反之并非总是如此，因为你可能会意外地敲掉字符串中的4个空格等。

Answer 15

当我第一次学习Python的时候，由于大多数使用它的语言都不灵活，我被大量空白的想法推迟了。也就是说，我对Python理解各种缩进样式的能力印象深刻。在考虑用于新项目的样式时，我认为记住两件事是很重要的。

1. 首先，了解Python如何解释缩进很重要。 Bryan Oakley在使用制表符时提到了逐个错误的可能性，但实际上这对于默认的解释器设置是不可能的。 O'Reilly在学习Python 中有更好的解释媒体。

基本上，有一个变量（可以通过在源文件＃tab-width：的顶部添加注释来更改）来定义选项卡宽度。当Python遇到标签时，它会将缩进距离增加到下一个标签宽度的倍数。因此，如果在文件的左侧输入一个选项卡后面的空格，则tab宽度的下一个倍数为8.如果输入一个选项卡，则会发生相同的事情。

通过这种方式，如果您的编辑器配置正确，使用标签，甚至混合标签和空格是安全的。只要将编辑器的制表符设置为与Python制表符宽度声明相同的宽度（如果不存在则为8）。除非您在文件中指定制表符宽度，否则使用制表符宽度不超过8个空格的编辑器通常是个坏主意。

1. 其次，Python的大部分语法设计都是为了鼓励同一个项目中程序员之间的代码可读性和一致的风格。也就是说，对于任何特定的项目，问题变成了什么使代码在项目工作的人中最具可读性。当然，保持一致的缩进样式是个好主意，但根据平台和项目使用的编辑器，不同的样式可能对不同的项目有意义。如果没有令人信服的理由不符合 PEP <！> nbsp; 8 ，这样做是有意义的，因为它符合人们的期望。

我遇到过成功使用标签和空格混合的项目。基本上空间用于缩进小部分，其中它在缩进部分的事实相对不重要;标签用于吸引读者注意大型结构特征。例如，类以tab开头，函数内的简单条件检查使用两个空格。

在处理缩进多个级别的大块文本时，选项卡也很有用。当您退出3-4级压痕时，使用正确的选项卡排队要比排列适当数量的空格容易得多。如果项目不使用PEP <！> 8推荐样式，最好将样式指南编写到某个文件中，以便缩进模式保持一致，其他人可以明确地阅读如何将其编辑器配置为匹配。

此外，Python 2.x有一个选项-t发出有关混合标签和空格的警告，-tt发出错误。这仅适用于同一范围内的混合制表符和空格。 Python <！> nbsp; 3假设<=>，据我所知，没有办法禁用该检查。

Answer 16

我主要是一名C ++程序员，但有时我的项目包含少量的Python。我使用制表符缩进我的C ++代码。这意味着我有三个选项：

1. 在C ++中使用制表符，在Python中使用空格。这允许我的C ++文件保持原样，我遵循PEP-8建议，但我在我的项目中不一致。
2. 更改我的C ++代码以使用空格。这允许我项目中的所有文件保持一致，并且我遵循PEP-8建议，但要求我返回并更改我的所有C ++文件。我认为这是一件坏事，因为我更喜欢标签。
3. 在我的C ++代码和Python代码中使用选项卡。这使我的整个项目保持一致，并允许我使用我喜欢的缩进样式：tabs。缺点是我没有遵循PEP-8标准。

对于我的项目，我通常选择3。

Answer 17

经验和 PEP-8 两者显然得出结论，混合的空间和 TABs是可以避免的。如果你想要混合他们的你必须要想象空白在IDE-但然后你失去了优势的蟒蛇的压痕制作范围容易看见。可视化的空白，在一个IDE会扰乱显示。

如果它是不是标签 或 空间，那么它就必须以空间为一个简单的原因：一个可以切换几乎所有的IDEs和文字编辑，以自动更换标签的空间，但相反是不正确的。

即使有IDEs，可以自动转换领先的空间中的行为标签，这最终将导致具有混合物的标签和空间。考虑多线声明诸如功能的电话有很多的参数或者doc串。虽然"ascii-技术"也是可以避免的，它可以很容易发生事故，一个单一的空间是后遗留下来的领先的标签。

其他的答案带来了若干论点，在有利于的标签：

• 击中 TAB 是效率更高。当然这是真实的，但所有文本的编辑允许立即插入的想数量的空格当选项关键压
• 缩进/Dedenting是更容易时，只有删除一个标签，而不是2/3/4/8空间。真的，但大多数文本的编辑允许这样做将自动无论如何：区块选择，缩/dedent是基本功能的一个编辑，就像评论/取消注释.如果一个文本编辑器还没有得到这种实现的，它至少应该有一个易于使用的宏功能与哪一个可以实现同样的事情。
• 不同的程序员等不同的缩进宽度。那是真实的，并明确优势的使用 TABs只。问题是相互作用与其他个人和/或团队。对于这项工作在现实世界中，每个人都会同意对所有使用 TABs只。由于这种情况并未发生，它不工作了。在一个真正的世界方案有一套编码指南，这一项目的同意后，无论如何，且该方法的压痕肯定是他们中的一个--甚至在其他的编程语言，这里所涉的问题是"只是"在一些级别。

恕我直言，主要的一点，大多数(如果不是全部)的答案都是在这里失踪的相互作用之间的团队或个人，特别是在方案参与者名单是不知道的开始。当代码代码满足所有必须使用标签或所有已经使用空间。它不能被混合而没有最终成功能的问题。人们都不是完美的。工具是不完美的。这就是为什么恕我直言我们不应该使用 TABs在所有。

没有答复是不完整的链接 格雷格提供了在他的回答 已经： 蟒蛇：神话有关的压痕

Answer 18

每个人对缩进代码的数量都有不同的偏好。假设您与某人共享代码，并且他或她对缩进有不同的偏好。如果缩进位于选项卡中，则您的朋友可以随时更改其编辑器设置中的选项卡宽度。但是，如果缩进位于空格中，如果他或她想要将其设置为首选项，您的朋友实际上必须更改源代码。然后，当您收到朋友的更改时，您可能会决定将其更改回您的偏好。在这种情况下，您要么必须处理来回更改缩进级别的单调乏味，要么一个人必须在缩进级别中采用其他人的首选项。如果你和你的朋友都使用标签，那么你有不同的偏好这一事实是没有问题的，因为你可以在代码保持不变的情况下看到不同的缩进级别。这就是为什么在我看来，制表符比所有编程语言中缩进的空格更好。

Answer 19

有一种情况，标签根本不起作用，即：根据您使用的编码风格，您可能需要将某些代码行缩进到一个空格的精度，即：

def foobar():
    x = some_call(arg1,
                  arg2)

在这种情况下，使用纯粹的标签根本不起作用;使用主缩进的制表符和子缩进的空格将起作用，但会违反不混合两者的硬规则。

但是在使用编码样式/约定文档时，情况并非如此，以避免出现上述代码示例中的情况。

Answer 20

使用空格而不是制表符的问题是文件大小变得非常大......例如，交换时，500 KB空间缩进文件可以减少到200 <！> nbsp; KB标签的空格，这就是我总是使用标签的原因。

较小的文件大小意味着更快的加载，编译，执行（在某些情况下）等等。

对我来说，没有必要使用空格，但如果有人使用了一个有选项卡问题的编辑器，那么它们可以替换<！> \ quot; \ t <！>用<！>“; <！> QUOT;或<！> quot; <！> QUOT;或者其他......

Answer 21

除了已经列出的所有参数之外，我发现这一点非常重要（来自神话）关于缩进）：

  

此外，在复制<！>放大器粘贴操作期间，或者在将一段源代码插入网页或其他类型的标记代码时，标签通常会被销毁或错误转换。

针对标签的另一个论点（特别是针对特定环境的）是手机键盘上有时会丢失。如果可能的话，可以通过安装替代键盘来解决这个问题。

标签的参数似乎没有人提到过1个标签是1个字符（0x09，文件中有1个字节），而4个空格是4个字符（4倍0x20，文件中的4个字节）;因此，使用空格会造成4倍的空间浪费。

为了总结这个不连贯的论点列表，我想在 Issue 7012：Tabs中引用Tim Peters的答案比缩进空间更好：

  

Python <！>“;仅限空格<！>”;标准是为了   分布式代码。多年的早期经验教会了我们毫无疑问的   标签为共享代码（...）

带来了无穷无尽的问题

Answer 22

这是如何发挥作用？

一些编辑人员配置，通过默认来取代一个单一的标签字有一定数量的空间字，但有些则不是。如果每个人使用的空间，这种差异在编辑默认设置可能被忽略。

是否还有其他原因为什么一个会使用的空间而不是标签的蟒蛇?或者是根本不真实的吗?

是的，有其他有效的理由如所指出的许多答复在我之前。"PEP-8"是这么说的，但是，是不是其中的一个原因。这是来自自我维持的神话，PEP-8是本编码标准 所有 代码，当事实上它只是编码标准的一套标准的蟒蛇图书馆。某一要求，PEP-8广泛接受，一些权利要求，大多数Python程序员使用的空间而不是标签。我谨要求证明这些权利要求，因为数量的选民在这个网站上清楚地表明，标签是优选的群众。我觉得很不幸你必须接受"述pep8是这么说的"作为回答你的问题，事实上还有许多其他的答案，实际上解释的相对优点和缺点的空间和标签。

我应该换我的编辑插入空间，而不是标签，或保持在会喜欢我？

这取决于，和在回答这最后一个问题就是我想我实际上可能增加一些值这个线程。恕我直言，不论语言被使用，最好的编码标准的使用取决于情况，你是：

• 如果你开始工作，在一个已经存在的码基础：不是很困难的，按照现有的编码标准
• 如果一个团队开始在一个新的项目从头开始:讨论、决定的编码标准的开始作为一个团队，并坚持下去
• 如果你要独唱：做任何让你感觉到的最幸福和最有生产力的

因此，这种情况你落下?

最后让我的立场明确，对于我自己的独的项目，使用标签标签，因为使更多的意义，我，我更富有成效的标签。

Answer 23

我相信有两种解决方案：

1. 与PEP-8的兼容性并使用空格
2. 使用制表符而不是4个空格的便利性

在Notepad ++中，转到<！> quot; preferences <！>“ - <！> gt; <！>“标签设置<！>”;并选择<！> quot; Python <！> quot;从右边的列表。然后确保<！>“;标签大小：4 <！>”;并选中<！>“框;用空格<！>替换[tab]。在这种情况下，您只需使用tab键缩进，但Notepad ++实际上会将其转换为4个空格。

Answer 24

截至7月，这是 PEP <！> nbsp; 8 2017：

看来这句话并没有为任何其他选择留下空间。

但这不仅仅是PEP <！> 8号告诉我们的事情，后面几行：

在上面，第一个语句表示空格的首选项，第二个语句表示存在使用制表符缩进的代码和某些编码器的首选项。

所以：PEP <！> nbsp; 8是标签缩进容忍。 它不能容忍标签和空格混合用于缩进，但由于缩进本身是强制性的，因此是可以理解的。

值得一提的是， Google的Python编码风格也遵循4空间规则。

还有其他各种论据和理由支持标签或4空格。

如果您在一家执行PEP <！> 8的公司工作，或定期与其他关注PEP <！> 8>的人分享您的代码，那么常识就决定了4个空间。我（曾经，也许）习惯于使用C / C ++中的标签。但是通过正确设置IDE，差异变得极小。

Answer 25

使用空格代替标签，唯一的原因是您可以赚更多钱：）

参考： 使用空间的开发人员钱比使用标签的人 （Stack Overflow博客文章）。

Answer 26

所以在这里，我正在阅读所有的回复，并想知道我如何能够遵守PEP-8，而不必反复敲击我的退格按钮以消除缩进，我低头看着我的罗技游戏键盘及其所有奇特的宏按钮我脑子里的灯泡亮起来了。

我打开了Logitech的软件，为选项卡按钮旁边的按钮定义了几个宏，问题就解决了。

一个按钮添加四个空格，另一个按钮添加退格四次。惊人。太棒了。用我的小指也很容易点击按钮。

看看，看看这个：<！> quot; <！>“<！> LT; - 四个空格！只需按一下按钮！如果我能告诉你退格，我也会这样做。去拿一台罗技G105键盘，你的所有问题都会消失！

Answer 27

我刚刚开始，但我发现使用制表符比空格容易得多，并且不了解PEP-8仅提供空格。 Sublime Text 2在使用灰白色的垂直虚线可视化标签方面表现非常出色，虽然有些情况下我混合了一两个空格来排列列表或字典中的元素，但我没有遇到过这样的情况。是有害的。

Answer 28

我喜欢标签，但它与我喜欢的其他规则不相容：80列限制。

如果选择4个空格标签并插入10个标签，则剩余空间可容纳40个字符以满足80列限制。 如果另一个编码器喜欢8个空格选项卡，则同一行将显示为120个字符长，并且不会显示为有效的80列线！

如果要定义80列限制，则必须为选项卡选择长度。在这种情况下，x空格或长度为x的标签并没有真正有所作为。

编辑：相关主题：维持最大行长何时使用制表符而不是空格？

Answer 29

我认为使用空间的主要好处之一就是消除了源代码在多种外部工具中的呈现方式的可变性，这些外部工具必须与选择编辑器之外的源交互以及它们配置它的任何设置英寸

一些具体示例考虑在 Visual Studio Code 中的工具提示中呈现Python文档字符串，或者在像 Beyond Compare 或 WinMerge ，性能或代码覆盖率工具等。基本上所有这些不同的其他接口工具都可以有不同的设置来解释标签的方式，它可以烦恼，有时迷失方向，找不到大不相同的东西，或者在你可能潜入和退出的工具集中远离屏幕。

简而言之，您在源代码中定义了对齐，而不是为您的工具库中的工具套件进行统一配置。空间严格按照等宽字体进行解释，以便在整个工具范围内提供可靠且一致的对齐，因为字体的定义不是第三方的选项卡渲染实现/配置。

另一个角度是复制前导标签源以在终端处运行，其中标签字符可以触发无意中的标签完成。例如，如果复制以下Python源（用作缩进的选项卡），

cmd_create_db = '''CREATE TABLE test (
    Col1 INTEGER,
    Col2 INTEGER,
    Col3 TEXT)'''

您可能会看到类似下面的内容（在Visual Studio Code的集成终端上看到）......

>>> cmd_create_db = '''CREATE TABLE test (
... .DS_StoreCol1 INTEGER,
... .DS_StoreCol2 INTEGER,
... .DS_StoreCol3 TEXT)'''
>>> cmd_create_db
'CREATE TABLE test (\n.DS_StoreCol1 INTEGER,\n.DS_StoreCol2 INTEGER,\n.DS_StoreCol3 TEXT)'

（旁白：我想知道这种对工具的一致性的观察是否是一个敏锐的开发人员想要订购世界的歧视性思维的标志，可能暗示对Stack上发现的工资差异的暗示<！> nbsp;溢出。）

Answer 30

我使用两个空格缩进和一个编辑器（kwrite），当我按Tab键时插入空格而不是制表符。