Python编程中的选项卡与空格
当我做Python编程时，我总是使用制表符缩进。 但后来我在这里遇到了一个问题，有人指出，大多数Python程序员使用空格而不是制表符来最小化编辑器到编辑器的错误。
这是如何影响的？ 还有其他的原因，为什么会使用空格，而不是标签为Python？ 或者是不是真的？
我应该切换我的编辑器插入空格而不是标签马上或继续像我以前一样去？
因为PEP-8告诉我们要使用空间。
厌倦了缩进错别字（8空格？没有，7哎呀9 …）我把我的来源切换到“仅制表”。
1标签== 1缩进级别，句号
重点是：如果要将缩进显示为4,8或pi / 12字符宽度，只需更改文本编辑器中的设置，不要乱用代码。
（就我个人而言，我使用4个字符宽度的标签…但有些人更喜欢3或8的空间，甚至使用可变宽度的字体。）
因此对主说：你要缩进四个空格。 不多不less。 四个是你要缩进的位置数，缩进的数目是四个。 八你不可缩进，也不可缩进你，除非你继续四下。 标签是正确的。 – Georg Brandl
使用编辑器，显示选项卡字符（所有空白，就此而言）。 你正在编程，而不是写文章。
我使用标签。 在选项卡中没有空间可用于单空间错误（如果可以看到它们）。 问题是人们使用不同的编辑器，世界上唯一的共同点是：tab == indent，如上所述。 有些家伙将tab键设置为错误的空格数量，或者手动进行，造成混乱。 标签和使用一个真正的编辑器。 （这不仅仅是与PEP相反，也是关于C / C ++和其他空白不相关的语言）。
/从肥皂箱中倒下
最“pythonic”的方式是每个缩进级别使用4个空格。 Python解释器会识别空格或制表符。 唯一的gottcha是你不能混合空格和制表符 ，挑一个或另一个。 也就是说，规范build议空间，大多数开发人员使用空间，所以除非你有一个非常好的理由不去，我会说空间。
我的主要原因是在空格上使用制表符是退格键。 如果我在一条线上，我想退格 – 删除一条线上的缩进，如果是空格，我必须退格4倍。 而如果它是一个标签，我只需要点击它一次。
我将继续使用制表符，因为像之前所说的那样，从制表符转换为空格更容易，而不是相反。
我想我想写一个简单的程序，将代码与空格转换成代码与标签，因为我吓坏了仇恨空间。 他们把我拉上了墙！
哦! 当使用箭头键左右移动时，如果是空格，总是会让人感到痛苦。
更新：崇高文本3现在删除一个完整的软标签与退格键; 虽然，箭头键导航仍然是单调乏味的。
更新：看到一些很酷的animationGIF，说明我的观点上面和更多在标签与空间，我们再次相遇
据我所知，这里有制表符和空格的优缺点。
优点标签：
- 缩进，取消缩进和遍历缩进所需的击键次数更less。 （即使你的IDE有一些空间缩进的聪明，它永远不会像标签一样好。）
- 不同的程序员可以根据需要使用不同的标签显示大小。
- 你永远不能有一个缩进字符“内”的光标。 例如，假设您正在复制一些行，使用制表符可以在行首附近隐约点击以开始您的select，您将获得第一个制表符。 有了空间，你很可能会错过第一个空间angular色，除非你击中它和边界之间的小目标。 类似地，从一行中删除缩进，如果您的光标位于四位缩进字符的中间，则大多数编辑器不会很好地处理退格键。 它通常会删除一个空间。 有了标签，它按预期工作。
- 与其他语言兼容，因此您不必设置编辑器即可使用，例如用于C ++ / Java的标签和用于Python的空格。
- 错误的缩进可能更明显（即额外的选项卡比一个额外的空间大得多）。
标签缺点：
- 大多数python程序员使用空格，所以你会违反惯例。
- 使用空格alignment多行语句比使用制表符更容易。 你可以使用tab-for-indentation，spaces-for-alignment，但是在Python中它似乎有点冒险！
有些人被一些非夸大的问题所困扰：
-
您可能会在标签缩进中出现杂乱无章的空间，这些空间会让事情变得糟糕：几乎所有的IDE /编辑器都支持可视化空白，而且您几乎可能会在空间缩进中看到杂乱的标签！ 无论如何，我看不出这是一个常见的错误。 此外， 大多数缩进错误都会被python捕获，好的IDE应该能够突出显示不同的缩进。
-
你不能很容易地把事情与标签alignment：如果你想要完美的alignment，这是真的，但是PEP-8build议不要这样做，而且python在多行语句中不能很好地运行。
-
人们在编辑器中对于标签显示大小有不同的设置，所以你的代码在不同的地方看起来会有所不同：是的，这实际上是标签的一个有益特性。
我已经开始使用空格来与其他python代码保持一致，但说实话，我很可能会改回标签。 很大程度上取决于IDE的function，但根据我的经验，没有太多的IDE支持空间缩进就像使用制表符一样好。
所以，除非你真的不喜欢与大多数 （大概不是全部！）python代码不一致，使用选项卡，并打开空白可视化和缩进高亮（如果可用）。 对我来说，最大的原因是易于select和（相当重要的IMO）击键的减less。 一些公约是愚蠢的。
我最近遇到了一篇名为Python：关于缩进的神话 ，讨论了这个问题和相关的问题。 在编写Python代码时，文章有充分的理由推荐使用空格，但是肯定会有不一致的地方。
我相信这是事实，大多数Python程序员只使用空格。
使用编辑器可以在按TAB键时插入空格，而不是插入\ t字符。 然后忘了它。
你可以混合制表符和空格…但是一个制表符被认为是与8个空格相同的缩进，所以除非你的编辑器被设置为把制表符认为是8个空格，否则在混合时要求麻烦。
我在使用空格而不是制表符时遇到的唯一不便是您无法轻松删除缩进级别，您必须删除4个空格而不是一个制表符。
制表符规则。 对于嵌套循环的相同的参数，你想把外环“回”1级。 提示：如果您想将旧的空间臃肿的Python代码转换为选项卡，请在http://www.textpad.com/add-ons/上使用TabOut实用程序作为可执行文件。;
我知道这是一个古老的问题，但它仍然出现在谷歌search的主题顶部附近，我想我可以添加一点价值。
当我第一次学习python的时候，由于大部分空白的想法，我放弃了一些，因为大多数使用python的语言都是不灵活的。 这就是说，我对Python了解各种缩进样式的能力印象深刻。 在考虑用于新项目的风格时，我认为记住两点是很重要的。
-
首先，了解python如何解释缩进非常重要。 Bryan Oakley在使用标签时提到了错误的可能性，但是这对于默认的解释器设置是不可能的。 O'Rielly Media在学习Python方面有更好的解释。
基本上，有一个variables（可以通过在源文件的顶部包括一个注释来改变，它定义了制表符的宽度）。 当python遇到一个标签时，它将缩进距离增加到下一个标签宽度的倍数 。 因此，如果沿着文件左侧input一个空格后跟一个制表符，则制表符宽度的下一个倍数为8.如果input了制表符，则会发生同样的情况。
这样，如果你的编辑器configuration正确，使用标签，甚至混合标签和空格是很安全的。 只要你把你的编辑器的制表位设置为和python制表符宽度声明相同的宽度（如果不存在，则为8）。 除非在文件中指定了制表符宽度，否则使用一个制表符宽度不超过8个空格的编辑器通常是一个坏主意。
-
其次，python的大部分语法devise都是为了鼓励同一个项目中的程序员之间的代码可读性和一致的风格。 这就是说，对于任何特定的项目来说，问题将变成什么使代码成为项目工作人员最易读的代码。 当然，保持一致的缩进风格是一个好主意，但是取决于项目所使用的平台和编辑器，不同的风格对于不同的项目可能是有意义的。 如果没有强制性的理由不符合pep8，那么这样做是有道理的，因为它符合人们的期望。
我遇到了成功使用了制表符和空格组合的项目。 基本上空格用于缩进小部分，其中缩进部分的事实相对不重要; 而标签则用于将读者的注意力吸引到一个大的结构特征上。 例如，类开始于一个选项卡，在一个函数内使用2个空格进行简单的条件检查。
当处理大量文本缩进多个级别时，选项卡也很有用。 当你退出3-4个缩进级别时，排列正确的标签要比排列适当的空间要容易得多。 如果一个项目不使用pep8推荐风格，最好在某个文件中编写风格指南，以便缩进模式保持一致，其他人可以明确地阅读如何configuration其编辑器以匹配。
此外，python2.x有一个选项-t发出关于混合制表符和空格的警告， -tt发出错误。 这只适用于相同范围内的混合制表符和空格。 python3假定-tt和我发现，没有办法禁用该检查。
经验和PEP-8都清楚地得出结论，混合空间和TAB是应该避免的。 如果你想把它们混合在一起，你必须在IDE中可视化空白 – 但是这样你就可以很容易地看到Python缩进的范围。 在IDE中可视化空白会使显示器杂乱无章。
如果它是TAB 或空格，那么它必须是空格，原因很简单：可以切换几乎所有的IDE和文本编辑器来自动replace空格的制表符，但事实恰恰相反。
即使有IDE可以自动将行中的前导空格转换为制表符，这最终会导致混合使用制表符和空格。 考虑多行语句，如带有大量参数或文档string的函数调用。 虽然“ascii艺术”也是要避免的，但可能很容易偶然发生在引导标签之后留下单个空间。
其他答案带来了几个赞成标签的理由：
- 打
TAB更有效率。 当然，这是真的，但是所有的文本编辑器都可以在按Tab键的时候立即插入想要的空格 - 当只需要移除一个标签而不是2/3/4/8空格时，缩进/缩进更容易。 诚然，大多数文本编辑器都允许自动完成这些操作：块select，缩进/缩进是编程编辑器的基本function，如注释/取消注释。 如果一个文本编辑器没有得到这个实现，至less应该有一个易于使用的macrosfunction，可以达到同样的目的。
- 不同的程序员喜欢不同的缩进宽度。 这是真的，只有使用
TAB的明显优势。 问题是与其他个人和/或团队的互动。 为了在现实世界中工作，每个人都必须同意所有使用TAB的情况。 由于这没有发生，反正它不起作用。 在现实世界中，无论如何，项目都有一套编码准则，而缩进方法当然也是其中之一 – 即使在其他编程语言中，其影响“仅”在视觉层面上也是如此。
Imho，大多数（如果不是全部的话）答案在这里缺失的主要原因是团队或个人之间的相互作用，特别是在参与者名单一开始就不知道的情况下。 当代码满足代码要么所有必须使用标签或所有必须使用空格。 没有最终遇到function问题，它是不能混合的。 人不完美。 工具并不完美。 这就是为什么我们不应该使用TAB的原因。
如果没有Greg在他的回答中提供的链接，没有答案是完整的： Python：关于缩进的神话
编辑器到编辑器的错误是在文件中混合缩进时发生的。 如下所示：一个代码块用4个空格缩进，然后一个缩进级别“in”，它是用制表符缩进的。 现在这样做的异教徒（混合标签和空格）有了它，所以他的标签也是4个空格，所以他没有看到任何问题，python也没有问题。 现在我们的受害者来了，他的标签设置为8个空格。 现在我们的受害者认为代码看起来都是重击，并通过去除一级缩进来 修复它 ，现在让代码看起来仍然是2级缩进，但实际上只是一个级别 。 在这一刻，所有的地狱都打破了。
这里的教训是，你永远不应该混合制表符和空格。 如果你坚持这样做，那么不pipe你自己使用哪一个，你的代码很容易重新join空格或制表符。 确保不混合制表符和空格的最佳方法是始终使用-tt运行python，这会在制表符和空格混合时产生错误。
至于制表符和空格，我个人使用制表符，使得单独的缩进与外观不同 – 使用制表符缩进时，更改代码外观比使用空格更容易。 我知道这跟99％的python程序员的做法是背道而驰的，但是这是我个人的偏好，在任何情况下都很容易将标签文件转换为间隔文件。 反过来并不总是正确的，因为你可以不小心敲出了4个string的空间等
我非常强烈地感觉到，无论历史惯例如何，制表符都是更好的select，应该替代未来编写的每一行Python代码中的空格。 就像踢出一个无能的暴君一样。 我的理由是： 单纯作为核心价值 。 使用两个或四个字符作为一个语义任务？ IMO没有超越传统的理由。
我主要是一个C ++程序员，但有时我的项目包含less量的Python。 我使用制表符缩进我的C ++代码。 这意味着我在这里有三个选项：
- 使用C ++中的标签和Python中的空格。 这允许我的C ++文件保持原样，并遵循PEP-8的build议，但是在我的项目中我不一致。
- 改变我的C ++代码使用空格。 这允许我的项目中的所有文件保持一致，并遵循PEP-8的build议，但要求我回去并更改所有的C ++文件。 我认为这是一件坏事，因为我更喜欢制表符。
- 在我的C ++代码和Python代码中使用选项卡。 这使得我的整个项目一致，并允许我使用我的首选缩进样式：标签。 缺点是我没有遵循PEP-8标准。
对于我的项目，我通常select3。
每个人都有不同的喜好，应该缩减多less代码。 假设您与某人共享代码，并且他或她对缩进有不同的偏好。 如果缩进是在制表符中，您的朋友可以随时更改其编辑器设置中的制表符宽度。 但是，如果缩进位于空格中，那么如果用户想将其设置为自己的偏好，则您的朋友实际上必须更改源代码。 然后，当你得到你的朋友的变化，你可能会决定改变回你的偏好。 在这种情况下，您将不得不面对来回更改缩进级别的单调乏味，或者一个人必须采用缩进级别中的对方偏好。 如果你和你的朋友都使用标签，那么你有不同的偏好是一个没有问题，因为你可以看到不同的缩进级别，而代码保持不变。 这就是为什么在我看来，制表符比所有编程语言中的缩进空间都好。
在这种情况下，制表符根本不起作用，即：根据您使用的编码风格，您可能需要将一些代码行缩进一空间精度，即：
def foobar(): x = some_call(arg1, arg2)
在这种情况下，使用纯粹的制表符根本无法工作; 使用标签为主要缩进和空间sub-indent将工作，但将违反不混合二的硬性规则。
但是，如果使用避免上述代码示例中的情况的编码风格/约定文档，情况并非如此。
除了已经列出的所有论据之外，我觉得这个很重要（ 关于缩进的神话 ）：
此外，在复制和粘贴操作期间，或者将一段源代码插入到网页或其他types的标记代码中时，标签通常会被破坏或错误地转换。
另一个参数（强烈环境特定，但是）对选项卡是他们有时在电话键盘上丢失 。 如果可能的话，可以通过安装替代键盘来解决这个问题。
没有人提到的标签的参数是1个标签是1个字符（0x09,1个字节在文件中），而4个空格是4个字符（4个0x20,4个字节在文件中）。 因此，使用空间会导致4倍的空间浪费。
为了总结这个不连贯的论证列表，我想引用Tim Peters在问题7012中的回答：Tabs比缩进空间要好 ：
Python“空间专用”标准适用于分布式代码。 多年的早期经验告诉我们毫无疑问，选项卡导致共享代码无尽的问题（…）
我已经阅读了所有的答案和大部分的最新评论，我相信我还有一些东西要补充，所以我要发表自己的答案。 （最近我一直在阅读很多有关在Python编程时使用制表符和空格的问题。）
我会尽量直接回答你的问题。
这是如何影响的？
有些编辑器默认configuration为用一组空格字符replace单个制表符，但有些编辑器却不是。 如果每个人都使用空格，则可以忽略默认编辑器设置中的差异。
还有其他的原因，为什么会使用空格，而不是标签为Python？ 或者是不是真的？
是的，我之前的许多答案都指出了其他有效的理由。 “PEP-8”是这样说的，但是，这不是其中的原因。 这来自PEP-8是所有Python代码的编码标准的自我延续的神话，实际上它只是标准Python库的编码标准。 有人声称PEP-8被广泛接受，有人声称大多数Python程序员使用空格而不是制表符。 我想问这些索赔的证据，因为这个网站上的票数清楚地显示标签是大众偏好的。 我觉得很遗憾的是，你们已经接受了“PEP8如此说”这个问题的回答，事实上还有很多其他答案可以解释空间和标签的相对优点和缺点。
我应该切换我的编辑器插入空格而不是标签马上或继续像我以前一样去？
取决于，最后一个问题的答案是我认为我可以为这个线程增加一些价值。 恕我直言，无论使用哪种语言，使用的最佳编码标准取决于您所处的情况：
- 如果您开始在现有的代码库上工作：不要难，请遵循现有的编码标准
- 如果一个团队从头开始一个新的项目：讨论，开始时作为一个团队来决定一个编码标准，并坚持下去
- 如果你要单独去做：做任何让你感到最快乐，最有成效的事情
那么你属于哪种情况呢？
最后，为了让自己的立场清晰起见，对于我自己的独立项目，我使用了制表符，因为制表符对我更有意义，对制表符我更有效率。
我刚刚开始，但我发现使用制表符比空格要容易得多，并且不理解PEP-8对空间的提倡。 崇高的文本2做了一个很好的工作，使用灰白色垂直虚线来显示制表符，虽然有些情况下我会混合一两个空格来排列列表或字典的元素，但是我还没有经历过这种情况是有害的东西。
我相信有一个解决scheme有两个：
- 与PEP兼容并使用空格
- 方便使用tab而不是4个空格
在记事本+ + +，进入“首选项” – >“选项卡设置”，并从右边的列表中select“Python”。 然后确保“标签大小：4”，并选中“空格replace[tab]”框。 在这种情况下，您可以简单地使用Tab键缩进，但记事本++实际上将其转换为4个空格。
我喜欢标签，但它与我喜欢的另一个规则有些不兼容：80列的限制。
如果select4个空格标签并插入10个标签，则剩余空间为40个字符以满足80列限制。 如果另一个编码器偏好8个空格标签，同一行将显示为120个字符长，并不会显示为有效的80列行！
如果你想定义一个80列的限制，那么你必须select一个标签的长度。 在这种情况下，有x个空格或长度为x的选项卡并没有真正的区别。
编辑：相关的线程： 使用制表符而不是空格时保持最大行长度？
截至2017年7月，这是PEP8 ：
看来这个声明没有留下任何其他select的空间。
但是这不仅仅是PEP8告诉我们的，几行之后： 
在上面，第一个语句表示对空格的偏好 ，第二个语句承认存在用制表符缩进的代码，并且这个偏好对于一些编码器。
所以 ：PEP8是tab压痕宽容。 它不允许混合缩进的tab和space ，因为缩进本身是强制性的，这是可以理解的。
值得一提的是， Google的Python编码风格也遵循四维空间规则。
还有其他各种论点和理由赞成标签或4空间。
If you work in a company which enforce PEP8, or regularly share your code with others who follow PEP8, then common sense dictates 4-space. I am (was, maybe) used to tabs from C/C++. But with a properly set IDE, the difference becomes minimal.
People will use different editors on the same code. These editors will represent a tab on the screen differently. If you're working on an editor that represents a tab as 4 spaces, if you indent the first line by "\t " and the second by "\t\t" , they'll look like they're in the same indent level: 8 spaces.
The python interpreter doesn't know your editor, and he has to interpret the tab as some amount of indentation. In fact, it interprets the tab as 8 spaces, so he'll see different indent levels than what you intended: 12 spaces for the first line, 16 spaces for the second. You're toasted.
I use two space indentation and an editor (kwrite) that inserts spaces instead of tabs when I hit the tab key.
Having recently had to deal with existing code that was mixing spaces and tabs, it's really confusing.
When you're mixing (which you really shouldn't do, but which does exist out there unfortunately), it appears that "1 tab == 1 indent level" isn't true.
Take the following example (tried with Python 2.7):
# Mostly use spaces class TestClass: def __init__(self): self.total = 0 def add(self, x): # 8 spaces at the start of the following line: self.total += x # SO automatically uses spaces, but use tabs in the next 2 lines. # One tab at the start of the following line: if self.total > 10: # Two tabs at the start of the following line: print "Greater than 10!" # Now use spaces again. return self.total tc = TestClass() print "Total: %d" % (tc.add(5),) print "Total: %d" % (tc.add(5),) print "Total: %d" % (tc.add(5),)
Here, there are 4 spaces before def add(...) (1 identation level), 8 spaces before self.total += x (2 indentation levels), and a single tab before if self.total > 10 .
Yet, that single tab behaves like 2 indentation levels, since this code works. In contrast, if you replace all tabs with 4 spaces (a single indentation level, that's where the def within the class are), you'll get an unexpected indent error before return , because it's no longer in a def block.
This is really confusing with editors that show tabs as 4 characters. Of course, this can be configured, but this also affect source code viewers (eg the likes of GitHub) where it's not necessarily easy to configure (or immediately visible that you need to do so, when you can).
The tab vs space behaviour will always depend on the editor:
- If your editor automatically inserts spaces whenever you press tab, it will insert the right number of spaces, so that another editor will display the exact same style.
- If your editor doesn't use tabs, there's always a chance that you won't notice a line that's using spaces instead of tabs (especially if other editors are used in the project).
Both have their downsides. The bottom line is that there needs to be an arbitrary choice between tabs and spaces, but they should never be mixed. Since you never know how your code is going to be read and used later, it's good to have a convention that affects all python coders. PEP-8 says spaces, so be it.
What matters is not to do it the Java way :
Four spaces should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4).
Yes… 1 tab = 2 indentation levels in the Java world! Thankfully, it doesn't have the same significance in terms of compilation.
I recently switched from tabs to spaces, for pep8 compliance.
I liked tabs previously for two reasons:
- With tabs, everyone can see code with the indentation level of their choice; just use spaces on the right and tabs on the left.
- make wants tabs pretty badly
…but after I realized how important pep8 has become, I switched anyway. As I see it, the chief value of spaces over tabs is simplicity – what you see is what you have. And pep8 compliance. And I came up with a vim rule that would turn on spaces for python files, leaving Makefile's tabbed.
The problem with using spaces instead of tabs is the file-size becomes so incredibly large.. For example a 500kb space-indented file could be reduced to 200kb when swapping spaces for tabs which is why I always use tabs.
Smaller file-size means faster loading, compiling, execution ( in some cases ), etc..
To me, there is no point to using spaces but if someone uses an editor which has issues with tabs, then they can replace "\t" with " " or " " or whatever..
