【Python】コーディング規約 PEP8を理解する

2023年8月24日

複数人のエンジニアやプログラマーが同一のプロジェクトを進める場合において、品質を保つためにコーディング規約が重要な役割を果たします。

一般的にコーディング規約は会社やプロジェクトで個別に規定されるものですが、PythonにはPEP8と呼ばれるコーディング規約が定められています。

この記事ではPEP8とその内容について紹介します。

PEP8とは

PEP8(Python Enhancement Proposal 8)はPythonのコーディング規約です。コーディング規約とはプログラミング言語のガイドラインのセットであり、コードの書き方やフォーマットに関するルールやガイドラインを定めたものです。複数の開発者が協力してコードを書く際に使用されます。

PEP8はコードを読みやすく、一貫性のあるコードベースをもたせるためのガイドラインが定められています。例えばインデントの書き方、1行の長さ、演算子の位置、空行の数、特定のモジュールや関数の書き方などです。

Pythonコミュニティでは、PEP8のガイドラインに従うことが推奨されており、Pythonの標準ライブラリや多数のオープンソースプロジェクトが、PEP8のコードスタイルを採用しています。

公式ドキュメント:https://peps.python.org/pep-0008/
公式ドキュメント(日本語):https://pep8-ja.readthedocs.io/ja/latest/

「一貫性にこだわりすぎるのは、狭い心の現れである」

「A Foolish Consistency is the Hobgoblin of Little Minds(一貫性にこだわりすぎるのは、狭い心の現れである)」

これは公式ドキュメントの冒頭に書かれているメッセージです。これにはいろいろな考え方があると思うので、一度公式ドキュメントを読んでみることを推奨します。

まず、Pythonの創設者であるGuidoさんは、コードは書かれることよりも、読まれることのほうが多いと洞察しているそうです。

そして、コーディング規約は一貫性をもたせるためのものであり、これに従うことは重要であるが、プロジェクト全体の一貫性を保つことは更に重要であり、特定の場面ではコーディング規約に従わないほうが良い場合もあると書かれています。

要するに場合によってコーディング規約は従わなくてもよいと言っているわけですが、

コーディング規約

ここではPEP8に書かれているガイドラインをざっくりと紹介します。また、一部を省略しています。公式ドキュメントに詳しく書かれているので不明な点はそちらをご確認ください。

インデント

  • インデントはスペース4つ
  • タブではなくスペースで(例外あり)
  • タブとスペースを混ぜることは禁止

1行の長さ

  • 行の長さは最大79文字
  • ドキュメンテーションやコメントは最大72文字
  • 長い行はバックスラッシュよりも括弧を使う
  • インデントを適切に行う

空行

  • 関数やクラスの定義は2行空けて行う
  • クラス内のメソッドの定義は1行空けて行う

import文

  • モジュールごとに行を分ける(例外あり)
  • ファイルの先頭に置く
  • グループ分けをして1行空白を置く(標準、サードパーティ、ローカル)

二重アンダースコア変数

  • あらゆるimport文の前に置く

式や文中

  • 式や文中に余計な空白文字を使わない
  • 行末に余計な空白文字を残さない
  • 2項演算子の両端に1つスペースを入れる
  • 引数などのデフォルトパラメータを示す等号(=)にはスペースを入れてはいけない(例外あり)
  • 複合文(一行に複数の文を入れること)は推奨されていない
  • 複合文でできた長い行を折り返してはいけない

コメント

  • コードと矛盾するコメントは書いてはいけない
  • コメントは複数の完全な文で書く
  • それぞれの文はピリオドで終わる
  • コメントが2つ以上の文からなる場合、文の終わりのピリオドの後はスペースを入れる(最後の文を除く)
  • 明解かつ分かりやすいコメントを書く
  • コメントは基本的に英語で書く

ブロックコメント

  • 一般的に適用されるコードの前に書く
  • コードと同じレベルにインデントをする
  • シャープの後にスペースを1つ入れる

インラインコメント

  • インラインコメントは控えめに使う
  • 文との間に少なくとも2つ以上のスペースを入れる
  • 自明なことを述べたインラインコメントはしない

ドキュメンテーション文字列

  • すべての公開されているモジュールは関数、クラス、メソッドのdocstringを書く
  • def文のあとに置くとよい
  • 複数行のdocstringは「”””」だけの文で閉じる(一行の場合は同じ行で閉じる)

命名規則

  • 実装よりも使い方を反映した名前にする
  • 単一の文字”l”(小文字のエル)、”O”(大文字のオー)、”I”(大文字のアイ)を変数に使ってはいけない
  • モジュールの名前は全て小文字の短い名前を使う(アンダースコアは推奨されていない)
  • クラスの名前には通常CapWords(最初の文字は大文字で、複数の単語を組み合わせる)方式を使う
  • 型変数の名前にも通常CapWords方式を使う
  • 例外はクラスであるべきなので、クラスの命名規則が適用される
  • 例外が実際にエラーである場合は名前の最後「Error」をつける
  • 関数の名前は小文字のみで、必要に応じて単語をアンダースコアで区切る
  • 変数の名前は、関数と同じ命名規則に従う
  • インスタンスメソッドのはじめの引数の名前は「self」を使う
  • クラスメソッドのはじめの引数の名前は「cls」を使う
  • 関数の引数名が予約語と被っていた場合、引数名の後ろにアンダースコアを追加するのが一般的には望ましい(略語を使用したり、スペルミスをするよりは好ましい。同義語を使うほうが良いかもしれない。)
  • メソッド名とインスタンス変数は関数の命名規則に従う
  • 公開されていないメソッドやインスタンス変数にだけ、先頭にアンダースコアを2つつける
  • 定数は全て大文字書き、単語をアンダースコアで区切る

プログラミングに関する推奨事項

  • 他のPython実装に不利にならないコードを書くとよい(PyPy, Jython, IronPython, Cython, Psycoなど)
  • Noneのようなシングルトンと比較をする場合は等値演算子を使ってはいけない
  • 拡張比較を使って並び替えを実装する場合、全ての演算を実装するのがよい
  • ラムダ式を直接識別子に結びつける代入文を書くのではなく、常にdef文を使う
  • 例外はBaseExceptionではなくExceptionから派生させる
  • 例外チェインを適切に使うとよい
  • 例外をキャッチするときは、特定の例外を指定するようにする
  • try/except文は「try」で囲む範囲を必要最低限にする
  • リソースがコードの特定の部分だけで使われる場合、with文を使う(try/finally文でもよい)
  • return文は一貫した書き方をする
  • ブール型の値とTrueやFalseを比較するのに「==」を使ってはいけない
  • try/finally文で制御構文(return、break、continue)を使うべきでない

あとがき

Pythonはコードの記述がシンプルな言語で、可読性が高いことが最大の特徴です。その可読性を保持するために、コーディング規約は大変重要な役割を果たします。

例えば、地方に旅行に行ったら、街中の至る所が方言で表記されていて、解読に困ってしまうなんてことがあったら嫌ですよね。

誰が見ても分かりやすく完璧なコード、それを目指していきたいですね。

以上、ここまで読んでいただき、ありがとうございました。