プログラミングには様々なお作法や暗黙的なルールがあります。
プログラムの書き方についてのルールがコーディング規約です。
このルールを知らないと他人から正しくコードを読んでもらえなかったり、チーム内で自分だけ違う書き方をしてしまうということになります。
コーディング規約は基本的に組織やチーム毎に決め、作成しますが、多くの場合は元にしているものがあります。
そこで本記事では、Pythonでよく使われる一般的なコーディング規約についてまとめます。
ある程度一人でプログラミングができるようになった方、組織やチームにまだコーディング規約がない方は、参考にしていただければと思います。
Pythonのコーディング規約
Pythonのコーディング規約のまとめとして、以下の内容を採り上げます。
- コーディング規約の種類
- 命名に関する規約
- フォーマットやレイアウトに関する規約
- コメントに関する規約
- その他の推奨事項
コーディング規約の種類
Pythonのコーディング規約は、代表的なものとして以下があげられます。
本記事では最も参考にされていると思われる『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のコーディング規約について紹介しました。
参考になれば幸いです。
コメント