使用 autopep8 前我们有必要先了解下 PEP 8 – Style Guide for Python Code
autopep8 automatically formats Python code to conform to the PEP 8 style guide. It uses the pycodestyle utility to determine what parts of the code needs to be formatted. autopep8 is capable of fixing most of the formatting issues that can be reported by pycodestyle.
Automatically formats Python code to conform to the PEP 8 style guide.
positional arguments: files files to format or '-'for standard in
optional arguments: -h, --help show this help message and exit --version show program's version number and exit -v, --verbose print verbose messages; multiple -v result in more verbose messages -d, --diff print the diff for the fixed source -i, --in-place make changes to files in place --global-config filename path to a global pep8 config file; if this file does not exist then this is ignored (default: ~/.config/pep8) --ignore-local-config don't look for and apply local config files; if not passed, defaults are updated with any config files in the project's root directory -r, --recursive run recursively over directories; must be used with --in-place or --diff -j n, --jobs n number of parallel jobs; match CPU count if value is less than 1 -p n, --pep8-passes n maximum number of additional pep8 passes (default: infinite) -a, --aggressive enable non-whitespace changes; multiple -a result in more aggressive changes --experimental enable experimental fixes --exclude globs exclude file/directory names that match these comma- separated globs --list-fixes list codes for fixes; used by --ignore and --select --ignore errors do not fix these errors/warnings (default: E226,E24,W50,W690) --select errors fix only these errors/warnings (e.g. E4,W) --max-line-length n set maximum allowed line length (default: 79) --line-range line line, --range line line only fix errors found within this inclusive range of line numbers (e.g. 1 99); line numbers are indexed at 1 --hang-closing hang-closing option passed to pycodestyle --exit-code change to behavior of exit code. default behavior of return value, 0 is no differences, 1 is error exit. return 2 when add this option. 2 is exists differences.
pycodestyle hello.py hello.py:1:10: E401 multiple imports on one line hello.py:3:1: E302 expected 2 blank lines, found 1 hello.py:4:69: E703 statement ends with a semicolon
$ autopep8 hello.py import os import sys defmain(): print [item for item in os.listdir('.') if item.endswith('.py')] print sys.version if __name__ == '__main__': main()
defexample1(): ####This is a long comment. This should be wrapped to fit within 72 characters. some_tuple=( 1,2, 3,'a' ); some_variable={'long':'Long code lines should be wrapped within 79 characters.', 'other':[math.pi, 100,200,300,9876543210,'This is a long string that goes on'], 'more':{'inner':'This whole logical line should be wrapped.',some_tuple:[1, 20,300,40000,500000000,60000000000000000]}} return (some_tuple, some_variable) defexample2(): return {'has_key() is deprecated':True}.has_key({'f':2}.has_key('')); classExample3( object ): def__init__ ( self, bar ): #Comments should have a space after the hash. if bar : bar+=1; bar=bar* bar ; return bar else: some_string = """ Indentation in multiline strings should not be touched. Only actual code should be reindented. """ return (sys.path, some_string)
defexample1(): # This is a long comment. This should be wrapped to fit within 72 # characters. some_tuple = (1, 2, 3, 'a') some_variable = { 'long': 'Long code lines should be wrapped within 79 characters.', 'other': [ math.pi, 100, 200, 300, 9876543210, 'This is a long string that goes on'], 'more': { 'inner': 'This whole logical line should be wrapped.', some_tuple: [ 1, 20, 300, 40000, 500000000, 60000000000000000]}} return (some_tuple, some_variable)
defexample2(): return (''in {'f': 2}) in {'has_key() is deprecated': True}
classExample3(object): def__init__(self, bar): # Comments should have a space after the hash. if bar: bar += 1 bar = bar * bar return bar else: some_string = """ Indentation in multiline strings should not be touched. Only actual code should be reindented. """ return (sys.path, some_string)
autopep8可以修复的问题
autopep8 fixes the following issues reported by pycodestyle:
E101 - Reindent all lines. E11 - Fix indentation. E121 - Fix indentation to be a multiple of four. E122 - Add absent indentation for hanging indentation. E123 - Align closing bracket to match opening bracket. E124 - Align closing bracket to match visual indentation. E125 - Indent to distinguish line from next logical line. E126 - Fix over-indented hanging indentation. E127 - Fix visual indentation. E128 - Fix visual indentation. E129 - Fix visual indentation. E131 - Fix hanging indent for unaligned continuation line. E133 - Fix missing indentation for closing bracket. E20 - Remove extraneous whitespace. E211 - Remove extraneous whitespace. E22 - Fix extraneous whitespace around keywords. E224 - Remove extraneous whitespace around operator. E225 - Fix missing whitespace around operator. E226 - Fix missing whitespace around arithmetic operator. E227 - Fix missing whitespace around bitwise/shift operator. E228 - Fix missing whitespace around modulo operator. E231 - Add missing whitespace. E241 - Fix extraneous whitespace around keywords. E242 - Remove extraneous whitespace around operator. E251 - Remove whitespace around parameter '=' sign. E252 - Missing whitespace around parameter equals. E26 - Fix spacing after comment hashfor inline comments. E265 - Fix spacing after comment hashfor block comments. E266 - Fix too many leading '#'for block comments. E27 - Fix extraneous whitespace around keywords. E301 - Add missing blank line. E302 - Add missing 2 blank lines. E303 - Remove extra blank lines. E304 - Remove blank line following function decorator. E305 - Expected 2 blank lines after end of function or class. E306 - Expected 1 blank line before a nested definition. E401 - Put imports on separate lines. E402 - Fix module level import not at top of file E501 - Try to make lines fit within --max-line-length characters. E502 - Remove extraneous escape of newline. E701 - Put colon-separated compound statement on separate lines. E70 - Put semicolon-separated compound statement on separate lines. E711 - Fix comparison with None. E712 - Fix comparison with boolean. E713 - Use 'not in'fortestfor membership. E714 - Use 'is not'testfor object identity. E721 - Use "isinstance()" instead of comparing types directly. E722 - Fix bare except. E731 - Use a def when use do not assign a lambda expression. W291 - Remove trailing whitespace. W292 - Add a single newline at the end of the file. W293 - Remove trailing whitespace on blank line. W391 - Remove trailing blank lines. W503 - Fix line break before binary operator. W504 - Fix line break after binary operator. W601 - Use "in" rather than "has_key()". W602 - Fix deprecated form of raising exception. W603 - Use "!=" instead of "<>" W604 - Use "repr()" instead of backticks. W605 - Fix invalid escape sequence 'x'. W690 - Fix various deprecated code (via lib2to3).
wangao@wangao-MAC ~ python3 Python 3.7.1 (default, Nov 62018, 18:46:03) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type"help", "copyright", "credits"or"license"for more information. >>> import this The Zen of Python, by Tim Peters
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
翻译
美 优于 丑
明确 优于 隐晦 (1)
简单 优于 复杂
复杂 也好过 繁复 (2)
扁平 优于 嵌套
稀疏 优于 拥挤
可读性很重要(3)
固然代码实用与否 比洁癖更重要,
我们以为的特例也往往没有特殊到必须打破上述规则的程度
除非刻意地静默,
否则不要无故忽视异常(4)
如果遇到模棱两可的逻辑,请不要自作聪明地瞎猜。
应该提供一种,且最好只提供一种,一目了然的解决方案
当然这是没法一蹴而就的,除非你是荷兰人(5)
固然,立刻着手 好过 永远不做。
然而,永远不做 也好过 不审慎思考一撸袖子就莽着干
如果你的实现很难解释,它就一定不是个好主意
即使你的实现简单到爆,它也有可能是个好办法
命名空间大法好,不搞不是地球人!
注释
该引入的包一个一个列出来不要合并;不要用星号;不要在方法里藏意想不到的的副作用,等等等等。还一个例子,另外一种著名的软件设计原则 Convention over Configuration(约定优于配置)如果做得不谨慎就会违背这条
SO: 必要的复杂逻辑是难免的,而繁复啰嗦的代码是不可接受的
Readability counts 不能翻译成可读性计数啊喂
实操中很多人不注意 catch 完就 log 一下 就不管了,这样不好。软件界一般都讲 Let it fail,学名为 Fail-fast 法则。简而言之就是整个项目周期中越早暴露的问题,其修复成本越低
本文作者 Tim peters 解释说这里的荷兰人指的是 Python 的作者 Guido van Rossum