blocks|key|3314617|text|如果您是源文件上唯一的程序员，并且没有强制执行特定样式的编码标准，那么请使用您喜欢的任何代码。就我个人而言(并且符合我们的编码标准)，我使用硬标签，以便任何正在查看代码的人都可以使用他们自己的偏好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3314618|要进行更改，您只需将所有行首空格更改为两倍大的空格即可。有很多方法可以做到这一点；在Vim文本编辑器中，我可以想到两种方法:第一：|3314619|:%25s/%5E$\s\{2}$\%2B/\=repeat('+',+len(submatch(0))*2)|code-block|syntax|javascript|3314620|这是一个简单的正则表达式，它在行首查找一对或多对空格，并将它们替换为所找到空格的两倍。通过使用以下命令打开vim，可以将其扩展为执行所有文件：|3314621|vim+*.py|3314622|(或等效项)，后跟(未测试)：|3314623|:argdo+%25s/%5E$\s\{2}$\%2B/\=repeat('+',+len(submatch(0))*2)/+%7C+w|3314624|或者：|3314625|"+Switch+to+hard+tabs:
:set+noexpandtab
"+Set+the+tab+stop+to+the+current+setting
:set+tabstop=2
"+Change+all+spaces+to+tabs+based+on+tabstop
:retab!
"+Change+the+tab+stop+to+the+new+setting
:set+tabstop=4
"+Go+back+to+soft+tabs
:set+expandtab
"+Replace+all+the+tabs+in+the+current+file+to+spaces
:retab|3314626|当然，许多其他工具也会提供类似的功能:如果像sed、awk、perl或python这样的工具不能很容易地做到这一点，我会感到惊讶。|offset|length|style|CODE|3314627|entityMap^0|0|0|0|0|0|0|0|0|0|M|3|Q|3|U|4|Z|6|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1B|8|@$W|1C|X|1D|Y|Z]|$W|1E|X|1F|Y|Z]|$W|1G|X|1H|Y|Z]|$W|1I|X|1J|Y|Z]]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|11|$]]

If you're the only coder working on your source file and there are no coding standards that enforce a particular style, use whatever you're comfortable with. Personally (and in line with our coding standard), I use hard tabs so that whoever is looking at the code can use their own preference.

To make a change, you simply need to change all start-of-line spaces to ones that are twice as large. There are many ways to do this; in the Vim text editor, I can think of two: firstly:

<pre><code>:%s/^$\s\{2}$\+/\=repeat(' ', len(submatch(0))*2)
</code></pre>

This is a simple regular expression that looks for one or more pairs of spaces at the start of the line and replaces them with twice as many spaces as were found. It can be extended to do all files by opening vim with:

<pre><code>vim *.py
</code></pre>

(or the equivalent), followed by (untested):

<pre><code>:argdo %s/^$\s\{2}$\+/\=repeat(' ', len(submatch(0))*2)/ | w
</code></pre>

Alternatively:

<pre><code>" Switch to hard tabs:
:set noexpandtab
" Set the tab stop to the current setting
:set tabstop=2
" Change all spaces to tabs based on tabstop
:retab!
" Change the tab stop to the new setting
:set tabstop=4
" Go back to soft tabs
:set expandtab
" Replace all the tabs in the current file to spaces
:retab
</code></pre>

Of course, many other tools will offer similar features: I would be surprised if something like <code>sed</code>, <code>awk</code>, <code>perl</code> or <code>python</code> couldn't do this very easily.

blocks|key|334523|text|标识和通用编码样式标准因语言和项目的不同而不同。采用编码风格标准有一个原因:这样代码看起来是统一的，不管是谁写的。这提高了项目的易读性，坦率地说，它看起来更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|334524|在采用编码风格标准时，有一个原因是无效的:因为您喜欢它。编码标准之所以存在，正是因为人们的喜好不同，如果任由他们自己选择，混乱就会随之而来，对所有人都不利。|334525|如果你只为自己写代码，没有人会读到，那就继续写你喜欢的代码吧。否则，遵循您所在社区的公认标准将使您的代码更容易为其他人所接受。还要记住，如果你决定将来为社区贡献代码，如果你已经习惯了他们的编码风格，你会更容易。|334526|至于更改选项卡大小，有许多支持Python的源代码格式化程序，并且大多数程序员的编辑器和IDE也具有此功能。您可能已经有了它，只需查阅您正在使用的编辑器的文档即可。|334527|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Identation and general coding style standards vary from language to language, project to project. There is one reason for adopting a coding style standard: so that the code look uniform, no matter who wrote it. That improves legibility in the project, and, to put it bluntly, it looks better.

There is one reason that is not valid when adopting a coding style standard: because you like it. Coding standards exists precisely because people's preferences vary, and if left to their own, chaos would ensue, to the detriment of all.

If you are writing code for yourself alone, which no one will ever read, go ahead and write it whatever you like. Otherwise, following the accepted standard of your community will make your code much more agreeable to everyone else's eyes. And remember, too, that if you DO decide to contribute code to a community in the future, you'll have an easier time if you are used to their coding style already.

As for changing the tab size, there are are many source code formatters out there which support Python, and most programmer's editors and IDEs also have this capability. You probably have it already, it's just a matter of consulting the documentation for the editor you are using.

blocks|key|3314659|text|没有“更好”的缩进。这是一个宗教圣战的话题。4是很好的，因为它足以使缩进清晰，但又不至于整个屏幕都是空白，你必须水平滚动才能阅读一半的程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3314660|它还有一个优点，那就是在历史上对“标签”的定义中，它是一个“半标签”。|3314661|除此之外，你可以使用你的团队喜欢的任何东西。就像巧克力和香草。|3314662|切换的一种简单方法是使用支持制表符和空格键的编辑器。将所有前导空格键转换为制表符，将制表符大小设置为4，然后将前导制表符转换回空格键。|3314663|使用python脚本也很容易做到。只需计算所有前导空格，然后在行首添加相同数量的空格，然后将其写回。|3314664|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

There's no "better" indentation. It's a religious holy-war topic. Four is nice because it's enough to make the indentation clear, but not so much that your whole screen is mostly whitespace and you have to scroll horizontally to read half the program.

It also has the upside of being a "half-tab" w/r to the historical definition of a "tab."

Other than that, use whatever your group likes. It's like chocolate vs. vanilla.

An easy way to switch is to use an editor that has tab and space-tab support. Convert all your leading space-tabs to tabs, set the tab size to four, and then convert leading tabs back to space-tabs.

Pretty easy to do with a python script too. Just count all the leading spaces, then add the same amount to the beginning of the line and write it back out.

blocks|key|337089|text|PEP不是你的老板。如果它已经一致地缩进了2个空格，那么就没有理由改变你所有的代码来符合它。如果你真的认为它很重要，你可以继续遵循它，但坦率地说，我不这么认为。你最好遵循惯例，让你(和你的同事)在阅读和写作方面都能获得最大的舒适感。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337090|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The PEP isn't the boss of you. If it's already consistently 2-space indented, there's no reason to change all your code to conform to it. You could follow it going forward if you really think it's that vital, but, frankly, I don't. You're better off going with whatever convention provides you (and your coworkers) the most comfort both in reading and writing.

blocks|key|3314746|text|其他人使用4个空格。这是我遇到并接受的使用4个空格的唯一原因。在我的心里，我仍然想使用制表符(每次缩进1个缩进字符，有意义，不是吗？将缩进与其他空格分开。我不关心制表符是否可以显示为不同的宽度，这在语法上没有区别。最坏的情况可能是一些评论不一致。太恐怖了！)但是我已经接受了，因为python社区作为一个整体使用了4个空格，所以我使用了4个空格。通过这种方式，我可以从别人编写的代码片段中组装代码，并且一切正常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3314747|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Everyone else uses 4 spaces. That is the only reason to use 4 spaces that I've come across and accepted. In my heart, I still want to use tabs (1 indent character per indent, makes sense, no? Separate indent from other whitespace. I don't care that tabs can be displayed as different widths, that makes no syntactic difference. The worst that can happen is that some of the comments don't line up. The horror!) but I've accepted that since the python community as a whole uses 4 spaces, I use 4 spaces. This way, I can assemble code from snippets others have written, and it all works.

blocks|key|337144|text|我认为真正的问题是为什么是空格而不是制表符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337145|选项卡显然更好：|337146|337147|这使得几乎不可能有不一致的缩进(我见过一些代码通常有4个空格缩进，但有些部分恰好少了一个空格，很难通过简单的检查来判断是有7个空格还是8个空格...这在制表符中是不会发生的，除非您将您的Tab键设置为1个空格)。记事本制表符是一个用于缩进的逻辑语义表示，它允许您(和任何其他开发人员)选择在不干扰其他人的记事本的情况下显示尽可能多的“空格”(或更确切地说，列)。如果您手头只有“记事本”(或其他虚拟编辑器)，则|unordered-list-item|offset|length|style|BOLD|337148|+is+|337149|<>H115添加和删除制表符是一个对称的操作。大多数集成开发环境可能会在按Tab键时自动插入4个空格，但通常它们在按退格键时只删除1个空格(取消缩进操作仍然可以通过shift-Tab键进行访问，但这是两个键的组合)，或者使用鼠标在缩进中间单击并删除一个character.|337150|They只需要1个字节而不是4个字节(乘以数千行就可以节省几KB！：p)|337151|您可以减少一件事情来解决协议，因为如果您决定使用空格，然后，讨论再次开始，以选择多少人(尽管共识似乎在4人左右)。|337152|337153|空格的优势：|337154|337155|Guido喜欢它们。|337156|您不能轻松地在此处键入制表符，它会转移焦点(尽管您可以粘贴)。|337157|337158|entityMap^0|0|0|0|3|C|3E|2|0|0|0|1|K|38|0|0|10|0|0|1L|0|0|0|6|0|0|0|A|0|0|V|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|17|8|@$H|18|I|19|J|K]|$H|1A|I|1B|J|K]]|9|@]|A|$]]|$1|L|3|M|5|G|7|1C|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1D|8|@$H|1E|I|1F|J|K]|$H|1G|I|1H|J|K]]|9|@]|A|$]]|$1|P|3|Q|5|G|7|1I|8|@$H|1J|I|1K|J|K]]|9|@]|A|$]]|$1|R|3|S|5|G|7|1L|8|@$H|1M|I|1N|J|K]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1P|8|@$H|1Q|I|1R|J|K]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|X|3|Y|5|G|7|1T|8|@$H|1U|I|1V|J|K]]|9|@]|A|$]]|$1|Z|3|10|5|G|7|1W|8|@$H|1X|I|1Y|J|K]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|20|8|@]|9|@]|A|$]]]|13|$]]

I think the real question is why spaces and not tabs.

Tabs are clearly better:

<ul>
<li>It makes nearly impossible to have inconsistent indentation (I've seen code that normally has 4 spaces indents, but then some parts happen to be one space off, it's difficult to tell by simple inspection if there are 7 or 8 spaces... That wouldn't happen with tabs, unless you set your tabstop to 1 space).</li>
<li>Tab is a logical semantic representation for indentation, it allows you (and any other developer) to choose to display as many "spaces" (or rather columns) you want without messing with other people's preferences.</li>
<li>It is also less keystrokes if you happen to have only "notepad" (or other dummy editor) at hand.</li>
<li>Adding and removing tabs is a symmetric operation. Most IDE's may insert automatically 4 spaces when hitting the tab key, but usually they remove just 1 space when hitting backspace (un-indent operation is still accessible as shift-tab, but that's a two key combination) or you use the mouse to click in the middle of the indentation and delete one character.</li>
<li>They take only 1 byte rather than 4 (multiply by thousands of lines and you save a few KB! :p)</li>
<li>You have one less thing to settle an agreement, because if you decide to go for spaces, then the discussion starts again to choose how many (although the consensus seems to be around four).</li>
</ul>

Advantages of spaces:

<ul>
<li>Guido likes them.</li>
<li>You cannot easily type a tab here, it transfers the focus (although you can paste one).</li>
</ul>

blocks|key|337163|text|使用4个空格或2个空格完全取决于您。4个空格只是一个约定。最重要的是，不要把制表符和空格混在一起。使用空格键|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337164|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

using 4 spaces or 2 spaces is entirely up to you. 4 spaces is just a convention. What is most important, don't mix tabs and spaces. Use the space bar

blocks|key|339573|text|任何一个像样的编辑器(emacs，vim)都会为你抽象出这些胡言乱语。它同样适用于空格或制表符，并且可以配置为使用任意数量的空格(或者说对于制表符使用任意数量的空格宽度)。它还可以毫不费力地在不同格式之间进行转换(参见vim中的:retab命令)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|339574|如果您正在尝试批量转换源代码格式，我建议您查看indent实用程序。|339575|也就是说，我忍不住要回答另一个问题。我的偏好一直是标签，因为它绕过了整个问题，每个人都可以查看他们认为合适的宽度设置的源代码。当你在编辑器中工作时，它也大大减少了输入，而编辑器对转换它没有帮助。就2个空格和4个空格而言，这纯粹是表面上的。|339576|entityMap|0|LINK|mutability|MUTABLE|url|http://www.linuxmanpages.com/man1/indent.1.php^0|36|6|0|N|6|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@$9|V|A|W|1|X]]|E|$]]|$1|H|3|I|5|6|7|Y|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

Any decent editor (emacs, vim) will abstract this whole nonsense out for you. It will work equally well with spaces or tabs, and it can be configured to use any number of spaces (or any number of space-widths for a tab character). It can also convert between the different formats without too much trouble (see the <code>:retab</code> command in vim).

If you're trying to convert source formatting in bulk, I recommend you take a look at the <a href="http://www.linuxmanpages.com/man1/indent.1.php" rel="noreferrer">indent</a> utility.

That said, I can't resist answering the other question... My preference has always been for tabs, since it bypasses the whole issue and everyone can view the source code with the widths set as they see fit. It's also a lot less typing when you're working in editors that aren't helpful with converting it. As far as 2 vs 4 spaces, that's purely cosmetic.

blocks|key|3314941|text|一个原因是，如果您使用较少的空格进行缩进，您将能够嵌套更多的语句(因为行长度通常限制为80)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3314942|现在我敢肯定，有些人仍然不同意多少嵌套构造应该是最大的。|3314943|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One reason is that if you use less spaces for indentation, you will be able to nest more statements (since line length is normally restricted to 80).

Now I'm pretty sure that some people still disagree on how many nested constructs should be the maximum.

blocks|key|3102120|text|我喜欢四个空格字符可以很好地缩进函数的内部代码，因为def+%2B一个空格就是四个字符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3102121|def·foo():
····pass|code-block|syntax|javascript|3102122|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I like the fact that four space characters nicely indents the inner code of a function, because def + one space makes four characters.

<pre><code>def·foo():
····pass
</code></pre>

blocks|key|336191|text|另一个原因是:当你有一些长的行(超过80个符号)并想将它拆分为2个时，你将只有1个空格来缩进，这有点令人困惑：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|336192|if+code80symbolslong+and+somelongvariablegoeshere+and+somelongerthan80symbols+\
+and+someotherstatementhere:
++#+some+code+inside+if+block
++pass

if+code80symbolslong+and+somelongvariablegoeshere+and+somelongerthan80symbols+\
++and+someotherstatementhere:
++++#+some+code+inside+if+block
++++pass|code-block|syntax|javascript|336193|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Also one of reasons is: when you have some long line (longer than 80 symbols) and want to split it in 2 you will have only 1 space to indent, that is a bit confusing:

<pre><code>if code80symbolslong and somelongvariablegoeshere and somelongerthan80symbols \
 and someotherstatementhere:
 # some code inside if block
 pass

if code80symbolslong and somelongvariablegoeshere and somelongerthan80symbols \
 and someotherstatementhere:
 # some code inside if block
 pass
</code></pre>

blocks|key|337208|text|如果你想和其他程序员一起写python代码，如果你和他们使用不同的缩进，就会有问题。大多数Python程序员倾向于使用4个空格的缩进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337209|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you want to write python code together with other programmers it becomes a problem if you use a different indention as them.
Most Python programmers tend to use 4-space indention.

blocks|key|336207|text|在视觉上识别带有4个空格的长嵌套代码块更容易。节省调试时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|336208|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It is easier to visually identify long nested code blocks with 4 spaces. Saves time when debugging.

While coding python I'm using only 2 spaces to indent, sure <a href="http://www.python.org/dev/peps/pep-0008/" rel="noreferrer">PEP-8</a> really recommend to have 4 spaces, but historically for me it's unusual.

So, can anyone convince me to use 4 spaces instead of 2? What pros and cons?

P.S. And finally, what's easy way to convert all existing codebase from 2 spaces to 4 spaces?

<hr>

P.P.S. PEP-8 Also srictly recommend not using tabs for indention. <a href="https://stackoverflow.com/questions/120926/why-does-python-pep-8-strongly-recommend-spaces-over-tabs-for-indentation">read here</a>

<hr>

So, to summarize:

Pros:

<ul>
<li>Have more space to arrange when wraping string more than 80 lines long.</li>
<li>Can copy code from snippets and it just works.</li>
</ul>

Cons: 

<ul>
<li>With deeper level of nested statements you have less space for actual code.</li>
</ul>

Thanks.

Python: using 4 spaces for indentation. Why?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在编写python代码时，我只用了2个空格来缩进，当然真的推荐有4个空格，但从历史上看，这对我来说并不常见。那么，有没有人能说服我用4个空格代替2个空格？什么利弊？另外，最后，有什么简单的方法可以将所有现有的代码库从2个空格转换到4个空格？P.P.S. PEP-8也强烈建议不要使用制表符进行缩进。所以，总结一下：优点：...

问Python:使用4个空格进行缩进。为什么？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python:使用4个空格进行缩进。为什么？EN