BETA

【俺的Advent Calendar 2018(2日目)】Pythonのコーディング規約 PEP8を読む

投稿日:2019-01-02
最終更新:2019-01-02

タダです。

Pythonを書くようになって、そもそもコーディグ規約も何も知らずに雑に書いてしまっていたなと自戒する機会があったので、この際に勉強しようと思います。

ありがたいことに日本語が用意されているので、読んで行きましょう。

コーディング規約PEP8

もっとも重要なのは、モジュールや関数での一貫性を保つこと

PEP8に準拠するのは大事だけど、モジュールや関数で一貫性を保つことが大切です。

ガイドラインに則ってなくてもいい場合もあります。

  • ガイドラインにそうと、コードが読みにくくなる
  • ガイドラインに沿っていない他のコードとの一貫性をもたせる
  • 問題のコードがガイドラインよりも前に書いたもの
  • ガイドラインで推奨されている機能をサポートしていない古いバージョンの Python と互換性を保つ必要がある場合

コードのレイアウト

インデントは、1つのインデントはスペースを4つ使います。

インデントの方法として、好ましいのは、タブではなくスペースを使うことです。

Python2のコマンドラインインタプリタにオプション(-t)をつけてよぶと、タブとスペースが混ざっていると警告が出ます。

-ttを使うとエラーになります。

1行の長さ

行の長さは、最大79文字までに制限します。

2項演算子の改行箇所

演算子の指揮は、常に2項演算子の前で改行をいれます。

空行

トップレベルの関数やクラスは、2行ずつ開けて定義するようにします。
また、クラス内部では、1行ずつ開けてメソッドを定義します。

ソースファイルのエンコード

常に、UTF-8を使うべき。

import

  • import文は行を分けるべき。
  • import文は、モジュールコメントやdocstoringの直後、モジュールのグローバル変数や定数定義の前に置くようにする
  • 次の順番でグループ化するべき
  1. 標準ライブラリ
    2.サードパーティに関連するもの
    3.ローカルなアプリケーション/ライブラリに特有のもの

モジュールのレベルの2重アンダースコア変数名

__all__ , __author__ , __version__ のような、モジュールレベルの二重アンダースコア変数は、モジュールに関する docstring の後、from __future__ 以外の あらゆるimport文の前に置くべき。

from __future__ import barry_as_FLUFL  

__all__ = ['a', 'b', 'c']  
__version__ = '0.1'  
__author__ = 'Cardinal Biggles'  

import os  
import sys

式や文中の空白文字

余計な空白文字を使わない

  • 括弧やブラケット、波括弧 のはじめの直後と、終わりの直前

    良い: spam(ham[1], {eggs: 2})  
    悪い: spam( ham[ 1 ], { eggs: 2 } )
    
  • 末尾のカンマと、その後に続く閉じカッコの間

    良い: foo = (0,)  
    悪い: bar = (0, )
    
  • カンマやセミコロン、コロンの直前

    良い: if x == 4: print x, y; x, y = y, x  
    悪い: if x == 4 : print x , y ; x , y = y , x
    
  • 関数呼び出しの引数リストをはじめる開き括弧の直前

    良い: spam(1)  
    悪い: spam (1)
    
  • インデックスやスライスの開き括弧の直前

    良い: dct['key'] = lst[index]  
    悪い:  dct ['key'] = lst [index]
    
  • 代入(や他の)演算子を揃えるために、演算子の周囲に1つ以上のスペースを入れる
    ```
    良い;
    x = 1
    y = 2
    long_variable = 3

悪い:
x = 1
y = 2
long_variable = 3


* 2項演算子は、両側に常に一つだけスペースを入れる。

i = i + 1
submitted += 1
x = x2 - 1
hypot2 = x
x + yy
c = (a+b)
(a-b)


* 関数では、コロン後にスペースをいれる

def munge(input: AnyStr): …
def munge() -> AnyStr: …
```

末尾にカンマをつけるべき場合

  • 基本は末尾にカンマをつけるかどうかは、任意。
  • 値や引数、もしくはimportされた値のリストが繰り返し展開されることが期待される場合や、バージョン管理システムを使っている場合が末尾にカンマを入れると便利なパターン。

コメント

  • コードの変更とコメントの修正は一緒にやる

その他のルール

  • ブロックコメントの各行は、#とスペース一つで設定できる
  • インラインコメントは、控えめに使う
    • 文とインラインコメントの間は少なくとも2つのスペースを置くべき。

命名規約

  • 公開されているAPIでユーザーに見える名前は、実装よりも使い方を反映した名前にすべき
  • 命名の一例
    • 小文字1文字
    • 大文字1文字
    • lowercase
    • lower_case_with_underscores
    • UPPERCASE
    • UPPER_CASE_WITH_UNDERSCORES
    • CapitalizedWords
  • 関数の名前は小文字のみにすべきで、読みやすさのために単語をアンダースコアで区切る
    • 変数も同様
  • インスタンスメソッドのはじめの引数の名前は常にselfを使う
    • クラスめっそのはじめの引数の名前は常にclsを使う
  • 定数は、通常モジュールレベルで定義し、大文字で書き、単語はアンダースコアで区切る

プログラミングの推奨事項

  • 他のPython実装 (PyPy, Jython, IronPython, Cython, Psyco など) で不利にならないようなコードを書くべき
  • None のようなシングルトンと比較をする場合は、常に is か is not を使うべき。絶対に等値演算子を使わない。

たくさんあるから参照して置けるようにしておこう。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@tada_infraの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう