PEP8項目まとめ その1(Code lay-out)
PythonのコーディングスタイルガイドPEP8について、PyPIで配布されてるpep8でチェックできる項目との対応をまとめる
(pep8モジュールですべての項目をチェックできる訳ではないようなので)
Code lay-out
Indentation
| PEP8 Item | pep8 ErrorCode |
| Use 4 spaces per indentation level. | E111 |
| Continuation lines should align wrapped elements either vertically using Python's implicit line joining inside parentheses, brackets and braces, or using a hanging indent. When using a hanging indent the following considerations should be applied; there should be no arguments on the first line and further indentation should be used to clearly distinguish itself as a continuation line. | E121, E122, E125, E126, E127, E128 |
| The closing brace/bracket/parenthesis on multi-line constructs may either line up under the last item of the list, or it may be lined up under the first character of the line that starts the multi-line construct | E123, E124 |
Tabs or Spaces?
| PEP8 Item | pep8 ErrorCode |
| Never mix tabs and spaces. The most popular way of indenting Python is with spaces only. | E101, E111 |
| For new projects, spaces-only are strongly recommended over tabs. Most editors have features that make this easy to do. | W191 |
Maximum Line Length
| PEP8 Item | pep8 ErrorCode |
| Limit all lines to a maximum of 79 characters. | E501 |
| For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. | -- |
| The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation. Make sure to indent the continued line appropriately. | E502 |
| The preferred place to break around a binary operator is after the operator, not before it. | -- |
Blank Lines
| PEP8 Item | pep8 ErrorCode |
| Separate top-level function and class definitions with two blank lines. | E302 |
| Method definitions inside a class are separated by a single blank line. | E301 |
| Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations). | E303 |
| -- | E304(blank lines found after function decorator) デコレーターに関する記述はPEP8には無い |
Encodings (PEP 263)
エンコーディングに関するチェックなし
| PEP8 Item | pep8 ErrorCode |
| Code in the core Python distribution should always use the ASCII or Latin-1 encoding (a.k.a. ISO-8859-1). For Python 3.0 and beyond, UTF-8 is preferred over Latin-1, see PEP 3120. | -- |
| Files using ASCII should not have a coding cookie. Latin-1 (or UTF-8) should only be used when a comment or docstring needs to mention an author name that requires Latin-1; otherwise, using \x, \u or \U escapes is the preferred way to include non-ASCII data in string literals. | -- |
| For Python 3.0 and beyond, the following policy is prescribed for the standard library (see PEP 3131): All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are not based on the latin alphabet MUST provide a latin transliteration of their names. | -- |
Imports
1行での複数import以外はチェックなし
| PEP8 Item | pep8 ErrorCode |
| Imports should usually be on separate lines. | E401 |
| Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants. | -- |
| Imports should be grouped in the following order: 1.standard library imports 2.related third party imports 3.local application/library specific imports | -- |
| You should put a blank line between each group of imports. | -- |
| Put any relevant __all__ specification after the imports. | -- |
| Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable. | -- |
意外とチェックされてない項目がいくつかあることが判明した。
- 作者: Tarek Ziade,稲田直哉,渋川よしき,清水川貴之,森本哲也
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2010/05/28
- メディア: 大型本
- 購入: 33人 クリック: 791回
- この商品を含むブログ (90件) を見る
