Pythonのコーディング規約【プログラミング初心者向け教材】

プログラミング

プログラミングには様々なお作法や暗黙的なルールがあります。

プログラムの書き方についてのルールがコーディング規約です。

このルールを知らないと他人から正しくコードを読んでもらえなかったり、チーム内で自分だけ違う書き方をしてしまうということになります。

コーディング規約は基本的に組織やチーム毎に決め、作成しますが、多くの場合は元にしているものがあります。

そこで本記事では、Pythonでよく使われる一般的なコーディング規約についてまとめます。

ある程度一人でプログラミングができるようになった方、組織やチームにまだコーディング規約がない方は、参考にしていただければと思います。

Pythonのコーディング規約

Pythonのコーディング規約のまとめとして、以下の内容を採り上げます。

  • コーディング規約の種類
  • 命名に関する規約
  • フォーマットやレイアウトに関する規約
  • コメントに関する規約
  • その他の推奨事項

コーディング規約の種類

Pythonのコーディング規約は、代表的なものとして以下があげられます。

  • PEP 8 [英語] [日本語]
    • Python公式のコーディング規約です。PEP(Python Enhancement Proposal)とは、Pythonの新機能や言語仕様などを公開している文書で、その中でPEP 8にコーディング規約に関する内容をまとめられています。
  • Google Python Style Guide [英語]
    • Google社が公開している、PEP 8を拡張したコーディング規約です。

本記事では最も参考にされていると思われる『PEP 8』の内容をまとめていきます。

命名に関する規約

命名 規則
パッケージ名
(ディレクトリ名)
全て小文字の短い名前
アンダースコアを使うのは推奨しない
mypackage
モジュール名
全て小文字の短い名前
アンダースコアを使ってもよい
my_module
クラス名
パスカルケース(アッパーキャメルケース)
MyClass
関数名
スネークケース(小文字のみ)
my_function
変数名
スネークケース(小文字のみ)
my_var
メソッド名
スネークケース(小文字のみ)
公開しないメソッドは先頭にアンダースコアをつける
my_method
インスタンス変数
スネークケース(小文字のみ)
公開しないインスタンス変数は先頭にアンダースコアをつける
my_instance_var
定数
スネークケース(大文字のみ)
MY_CONSTANT
引数名
インスタンスメソッドの最初の引数名にselfを使う
クラスメソッドの最初の引数名にclsを使う

こんな名前は嫌だ

単一の文字 ‘l’ (小文字のエル)、’O’ (大文字のオー)、’I'(大文字のアイ) を決して変数に使わないでください。
フォントによっては、これらの文字は数字の1や0と区別が付かない場合があります。’l'(小文字のエル) を使いたくなったら、’L’ を代わりに使います。

予約語と重複する名前を使用したい場合

変に省略名を付けるのではなく、名前の最後にアンダースコアを付ける。

コードのフォーマットに関する規約

インデント

インデントにはタブではなく、スペースを使うようにします。

1レベルインデントするごとに、スペース4つを使います。
折り返す場合は、折り返した要素を縦に揃えます。

# 開き括弧に揃える
foo = long_function_name(var_one, var_two,
                         var_three, var_four)

# 引数とそれ以外を区別するため、スペースを4つ(インデントをさらに)加える
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

# 突き出しインデントはインデントのレベルを深くする
foo = long_function_name(
    var_one, var_two,
    var_three, var_four)

1行の長さ

すべての行の長さを、最大79文字までとします。
チーム内で合意が得られれば、1行99文字まで制限を緩めてもOKです。
コメントなどのテキストのブロックについては、1行72文字までとします。

折返しは、括弧やブラケット(角括弧)、波括弧で折り返します。

空行

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

関数の中では、ロジックの境目を示すために、空行を控えめ(通常1行)に使うようにします。

ソースファイルのエンコーディング

基本的にすべてUTF-8を使います。
UTF-8を使用しているファイルにエンコーディング宣言は不要です。

import

import文は、行を分けて、常にファイルの先頭に記述します。
相対importではなく、絶対importを使うようにします。
ワイルドカードを使ったimportは、どの名前が名前空間に存在しているかをわかりにくくするため、避けたほうが良いです。

文字列に含まれる引用符

Pythonでは、単一引用符で囲まれた文字列と、二重引用符で囲まれた文字列は同じです。
どちらを使うかは、ルールを決めて統一されていれば、どちらでも構いません。
文字列の中に、単一引用符または二重引用符が含まれている場合は、バックスラッシュ(エスケープ)を使うことを避けるため、もう一方の引用符を使うようにします。

式や文中の空白文字

以下の時に、余計な空白文字は付けないようにします。

  • 括弧やブラケット、波括弧のはじめの直後と終わりの直前
# 正しい:
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
  • 行末に余計な空白文字は残さない。
  • 代入演算子や拡張演算子、比較演算子、ブール演算子は、両側にスペースを1つ入れる。
  • 優先順位が違う演算子を扱う場合、優先順位が一番低い演算子の両側にスペースを入れる。
# 正しい:
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

# 間違い:
i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

コメントに関する規約

ブロックコメント

ブロックコメントは、その後に続くいくつかのコードに適用され、そのコードと同じレベルにインデントされます。
ブロックコメントの各行は、# とスペース一つから始めます。

インラインコメント

インラインコメントは、文と同じ行に書くコメントです。
文とインラインコメントの間は、少なくとも二つのスペースを空けます。
インラインコメントは、# とスペース一つから始めます。

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

良いドキュメンテーション文字列(docstrings)を書くための規約は、PEP257 にまとめられています。

その他の推奨事項

  • 例外クラスは、BaseExceptionではなくて、Exceptionから派生するようにします。
  • 例外を捕捉する時には、可能な限りexcept文に特定の例外を指定するようにします。
  • すべてのtry/exceptについて、tryで囲む範囲を必要最小限のコードに限るようにします。
  • リソースがコードの特定の部分だけで使われる場合は、後始末が忘れずにできるようにwith文を使います。
  • stringモジュールよりも、文字列メソッドを使うようにします。
  • ブール型の値とTrueやFalseを比較するのに、==を使うのはやめましょう。ifの条件式にそのまま指定します。
  • try…finallyの組合せの中で、finallyの外に脱出するreturn、break、continueを使うのは推奨されません。

ツールを使って自動的にチェックできるようにしよう

コーディング規約は、多くの場合、プロジェクトや組織ごとに異なります。

それらをすべて覚えてプログラミングするのは、返って効率が悪くなる場合があるので、主要な部分は覚えて、細かい部分はツールでチェックできるようにすると良いです。

IDEにツールが備わっている場合もありますし、それぞれのコーディング規約に沿ったチェックツールが提供されている場合もあります。

それらを上手く活用し、自分たち向けにカスタマイズして、誰もが同じ規約のもとで、同じようにコードが書けるようにするのがベターです。

今回はPythonのコーディング規約について紹介しました。

参考になれば幸いです。

コメント

タイトルとURLをコピーしました