Python: 使用4个空格进行缩进。为什么?

在编写 python 代码时,我只使用了2个空格来缩进,当然 PEP-8确实建议使用4个空格,但是从历史上看,这对我来说是不寻常的。

那么,有人能说服我使用4个空格而不是2个吗? 有什么好处和坏处呢?

最后,有什么简单的方法可以将所有现有的代码库从2个空间转换成4个空间?


PEP-8还严格建议不要使用制表符进行缩进


总结一下:

优点:

  • 当包装字符串长度超过80行时,需要更多的空间来排列。
  • 可以从代码片段中复制代码,并且它可以正常工作。

缺点:

  • 随着嵌套语句级别的提高,实际代码的空间变得越来越小。

谢谢。

104692 次浏览

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:

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

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:

vim *.py

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

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

Alternatively:

" 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

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

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.

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.

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.

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.

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

Tabs are clearly better:

  • 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).
  • 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.
  • It is also less keystrokes if you happen to have only "notepad" (or other dummy editor) at hand.
  • 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.
  • They take only 1 byte rather than 4 (multiply by thousands of lines and you save a few KB! :p)
  • 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).

Advantages of spaces:

  • Guido likes them.
  • You cannot easily type a tab here, it transfers the focus (although you can paste one).

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

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 :retab command in vim).

If you're trying to convert source formatting in bulk, I recommend you take a look at the indent 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.

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.

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

def·foo():
····pass

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:

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

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.

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