Pythonコードスタイルとチェックツールのガイド

Pythonのコードスタイルガイドは決まったものではありません。言語の発展に伴い、継続的に進化しています。古い慣習が徐々に廃止され、新しいものが次々と登場します。同時に、多くのプロジェクトには独自のコーディングスタイルガイドがあります。競合が生じた場合、まずはプロジェクト固有のガイドに従う必要があります。ただし、重要な原則があります。「一貫性のための愚かな執着は無知の怪物である」という、Guidoによる深い洞察です。コードは書くよりも頻繁に読み取られることが多いため、スタイルガイドの核心的な目標はコードの可読性を向上させ、様々なPythonコードを一貫させることです。PEP20に記載されているように、「可読性が重要である」です。

スタイルガイドは一貫性を強調しています。ガイドとの一貫性が重要ですが、プロジェクト内の一貫性がさらに重要であり、モジュールや関数内の一貫性は最も重要です。もちろん、スタイルガイドの一部を無視する合理的な状況もあります。例えば、ガイドを適用するとコードの可読性が低下する場合、周辺の歴史的なコードとの一貫性を保つと全体構造が損なわれる場合、ガイドが制定される前に存在していたコードで修正する必要がない場合、コードが古いバージョンのPythonの機能と互換性を持たなければならない場合などです。特に、PEPに従うためだけに下位互換性を破ってはいけません！

コードレイアウト

インデント

インデントの各レベルには一様に4つのスペースを使用します。
括弧内では垂直の暗黙のインデントまたはハンギングインデントを使用できます。ハンギングインデントを使用する場合、最初の行にはパラメータを含めず、その後の行はインデントする必要があります。例えば：

# 開始デリミタと揃える
leapcell_foo = long_function_name(var_one, var_two,
                                 var_three, var_four)

# 他のコードと区別するために、より多くのインデントを使用する
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

# ハンギングインデント、さらに1レベルのインデントを追加する必要がある
leapcell_foo = long_function_name(
    var_one, var_two,
    var_three, var_four)

連続する行の場合、4つのスペースのインデントは必須ではありません。

if文が複数行にまたがる場合、ifキーワードにスペースを加え、その後に左括弧を使用してインデントします。その後の行には複数の形式があり、追加のインデントをしない形式、コメントを追加する形式、または追加のインデントをする形式（推奨）などです：

# 追加のインデントをしない
if (this_is_one_thing and
    that_is_another_thing):
    do_something()

# コメントを追加する
# 構文ハイライトをサポートする。
if (this_is_one_thing and
    that_is_another_thing):
    # 両方の条件が真のため、frobnicateすることができます。
    do_something()

# 追加のインデントをする、推奨
if (this_is_one_thing
        and that_is_another_thing):
    do_something()

閉じ括弧が新しい行にある場合、閉じ括弧をバックアップする形式が推奨されます：

# 閉じ括弧をバックアップする
leapcell_my_list = [
    1, 2, 3,
    4, 5, 6,
]
leapcell_result = some_function_that_takes_arguments(
    'a', 'b', 'c',
    'd', 'e', 'f',
)

スペースまたはタブ

スペースがインデントの好ましい方法です。
既存のタブでインデントされたコードと一貫性を保つ必要がある場合にのみ、タブを使用します。
Python 3ではタブとスペースを混在させたインデントを厳禁としています。Python 2での混在インデントのコードはすべてスペースインデントに変換する必要があります。Python 2のコマンドラインインタプリタは、-tオプションを使用して不正な混在インデントに関する警告を発行でき、-ttオプションは警告をエラーに昇格させます。これらの2つのオプションを使用することを推奨します。同時に、pep8とautopep8モジュールを推奨します。

最大行幅

すべてのコード行の最大幅は79文字に制限され、ドキュメント文字列またはコメントの行長は72文字に制限されます。
チームで合意が得られた場合、行幅を80文字から100文字（最大99文字）に増やすことができますが、ドキュメント文字列とコメントは引き続き72文字の長さを維持することを推奨します。Python標準ライブラリは、より保守的な行幅制限である79文字（ドキュメント文字列/コメントは72文字）を採用しています。
行を続ける好ましい方法は、括弧、角括弧、波括弧を使用することです。バックスラッシュは適切なシナリオで使用でき、例えばwith文の場合：

with open('/path/to/some/file/you/want/to/read') as leapcell_file_1, \
     open('/path/to/some/file/being/written', 'w') as leapcell_file_2:
    leapcell_file_2.write(leapcell_file_1.read())

二項演算子の行継続

二項演算子で行を続ける場合、従来の推奨は演算子の後で改行することですが、これは可読性に影響を与える場合があります。数学的な慣習に従って、二項演算子の前で改行することが通常、コードをより可読性の高いものにします。Pythonコードでは、ローカル的に一貫性がある限り、演算子の前または後で改行することが許されます。新しいコードの場合、演算子の前で改行するKnuthスタイルを採用することを推奨します：

# 演算子がオペランドと簡単に一致する
leapcell_income = (gross_wages
                  + taxable_interest
                  + (dividends - qualified_dividends)
                  - ira_deduction
                  - student_loan_interest)

空白行

トップレベルの関数とクラスの定義は、2つの空白行で区切ります。
クラス内のメソッド定義は、1つの空白行で区切ります。
関数内の異なる関数グループまたは論理ブロックを必要に応じて区切るために、追加の空白行を使用できますが、過剰な使用は避ける必要があります。

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

核心的なPythonリリースのコードは常にUTF-8（Python 2ではASCII）を使用する必要があります。
ASCIIファイル（Python 2）またはUTF-8（Python 3）にはエンコーディング宣言は不要です。標準ライブラリのデフォルト以外のエンコーディングは、テスト用、または非ASCII文字（例えば作者名）を含むコメントやドキュメント文字列にのみ使用されます。この場合、\x、\u、\Uまたは\Nを使用することを試みてください。
Python 3.0以降のバージョンでは、PEP 3131を参照して、標準ライブラリではASCII識別子を使用する必要があり、可能な限り英字のみを使用する必要があります。文字列とコメントもASCIIである必要がありますが、非ASCII関数をテストする場合と非ラテンアルファベットの作者名を除いてはそうです。

インポート

インポート文は1行で記述する必要があります：

# 正しい例
import os
import sys

# 誤った例
import sys, os

次の形式も使用できます：

from subprocess import Popen, PIPE

インポート文は、ファイルの先頭、モジュールコメントとドキュメント文字列の後、モジュールのグローバル変数と定数の前に記述する必要があります。インポートの順序は、標準ライブラリのインポート、関連するサードパーティライブラリのインポート、ローカルライブラリのインポートであり、各グループのインポートを空白行で区切ります。
allに関連するインポートは、他のインポートの後に記述する必要があります。
絶対パスインポートを使用することを推奨します。なぜなら、それらはより可読性が高く、より良好なパフォーマンスを発揮する（または少なくともより良好なエラーメッセージを提供できる）からです：

import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

絶対パスが長すぎる場合、相対パスインポートを使用できます：

from . import sibling
from .sibling import example

標準ライブラリのコードは、複雑なパッケージレイアウトを避ける必要があり、常に絶対インポートを使用する必要があります。暗黙の相対インポートは避ける必要があり、Python 3では削除する必要があります。

クラスをインポートする場合、次の方法を使用できます：

from myclass import MyClass
from foo.bar.yourclass import YourClass

ローカルな名前の衝突がある場合、次のように使用できます：

import myclass
import foo.bar.yourclass

ワイルドカードインポート（from <module> import *）は禁止されています。なぜなら、それによって名前空間が不明確になるからです。外部APIを再公開する場合にのみ、検討することができます。

文字列の引用符

Pythonでは、シングルクォートで囲んだ文字列とダブルクォートで囲んだ文字列は同じ機能を持っています。文字列内のバックスラッシュを避けるようにして、可読性を向上させます。
PEP 257に従って、トリプルクォートで囲んだ文字列はダブルクォートを使用する必要があります。

式と文の中のスペース

括弧内にスペースを追加しないでください：

# 正しい例
spam(ham[1], {eggs: 2})
# 誤った例
spam( ham[ 1 ], { eggs: 2 } )

末尾のコンマと閉じ括弧の間にスペースを入れないでください：

# 正しい例
leapcell_foo = (0,)
# 誤った例
leapcell_bar = (0, )

コンマ、コロン、セミコロンの前にスペースを入れないでください：

# 正しい例
if x == 4: print x, y; x, y = y, x
# 誤った例
if x == 4 : print x , y ; x , y = y , x

インデックス操作では、演算子としてのコロンの前後にスペースを一貫して使用する必要があります（スペースを使用しないことを推奨します）：

# 正しい例
ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
ham[lower:upper], ham[lower:upper:], ham[lower::step]
ham[lower+offset : upper+offset]
ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
ham[lower + offset : upper + offset]

# 誤った例
ham[lower + offset:upper + offset]
ham[1: 9], ham[1 :9], ham[1:9 :3]
ham[lower : : upper]
ham[ : upper]

関数呼び出しの左括弧の前にスペースを入れないでください：

# 正しい例
spam(1)
dct['key'] = lst[index]

# 誤った例
spam (1)
dct ['key'] = lst [index]

アサイン演算子やその他の演算子の前後に、整列を目的として複数のスペースを追加しないでください：

# 正しい例
leapcell_x = 1
leapcell_y = 2
leapcell_long_variable = 3

# 誤った例
leapcell_x             = 1
leapcell_y             = 2
leapcell_long_variable = 3

コードチェックツール

ソフトウェアプロジェクトの保守において、一貫したコードスタイルとテスト基準を維持することは極めて重要です。これにより保守の負荷を軽減し、新しい開発者がプロジェクトに迅速に慣れるのに役立ち、アプリケーションの品質を保証することができます。外部ライブラリを使用してコードの品質をチェックすることは、プロジェクトの保守性を維持するための効果的な手段です。以下は、一般的に使用されるPythonのコードスタイルチェックとフォーマット化ツールです。

コードスタイルチェックツール

Pylint：PEP 8仕様の違反や一般的なエラーをチェックするためのライブラリです。人気のエディタやIDEに統合することができ、コマンドラインからの実行もサポートしています。pip install pylintでインストールした後、pylint [options] path/to/dirまたはpylint [options] path/to/module.pyを使用してチェックし、結果はコンソールに出力されます。また、pylintrc設定ファイルを介してチェックルールをカスタマイズすることもできます。
Flake8：PEP 8、Pyflakes（Pylintに似ています）、McCabe（コードの複雑度チェッカー）、およびサードパーティプラグインを統合しており、Pythonコードのスタイルと品質をチェックするために使用されます。インストールコマンドはpip install flake8で、flake8 [options] path/to/dirまたはflake8 [options] path/to/module.pyを実行してエラーと警告を表示します。設定ファイルを介してチェック内容をカスタマイズすることができます。ドキュメントには便利なコミットフックが提供されており、開発ワークフローに統合することができます。また、プラグイン（例えばSublime Text用のFlake8プラグイン）を介してエディタやIDEに統合することもできます。
Isort：プロジェクト内のインポートされたライブラリをアルファベット順にソートし、標準ライブラリ、サードパーティライブラリ、自作ライブラリなどの部分を正しく区切ることができ、コードの可読性を向上させます。pip install isortでインストールし、isort path/to/module.pyを実行します。.isort.cfgファイルを設定することで、ライブラリの複数行のインポートも処理することができます。人気のエディタやIDEとの統合もサポートしています。

コードフォーマット化ツール

Autopep8：指定されたモジュールのコードを自動的にフォーマット化します。これには、行の再インデント、インデントの修正、不要なスペースの削除、一般的な比較エラー（例えばブール値とNone値）のリファクタリングなどが含まれます。pip install --upgrade autopep8でインストールし、autopep8 --in-place --aggressive --aggressiveを実行してコードをフォーマット化します。aggressiveオプションの数によって、コードスタイルの制御の程度が決まります。
Yapf：PEP 8仕様に違反している箇所を指摘するだけでなく、スタイルが一貫していないが仕様に違反していないコードを再フォーマット化し、可読性を向上させることができます。インストールコマンドはpip install yapfで、yapf [options] path/to/dirまたはyapf [options] path/to/module.pyを使用してコードをフォーマット化します。完全なカスタマイズオプションのリストを介して設定することができます。
Black：比較的新しいコードチェックツールです。Autopep8やYapfと似ていますが、カスタマイズオプションが少なく、手動でコードスタイルを決定する必要がありません。Python 3.6以上に依存しており、Python 2のコードもフォーマット化することができます。pip install blackでインストールし、black path/to/dirまたはblack path/to/module.pyを実行してコードを最適化します。限られたカスタマイズオプションと設定方法を参照することができます。

テストカバレッジチェックツール

Coverage：テストのカバレッジを計算するために使用され、複数の表示方法を提供しています。例えば、コンソールやHTMLページに出力し、カバーされていないコード行にマークを付けます。設定ファイルを介してチェック内容をカスタマイズすることができます。インストールコマンドはpip install coverageで、coverage [path/to/module.py] [args]を実行してプログラムを実行し、結果を表示します。coverage report -mを使用して、カバーされていないコード行を表示することができます。

Leapcell: サーバレスウェブホスティングのベスト

最後に、Pythonサービスをデプロイするのに最適なプラットフォームをお勧めします：Leapcell

🚀 好きな言語で構築

JavaScript、Python、Go、またはRustで簡単に開発できます。

🌍 無料で無制限のプロジェクトをデプロイ

使用する分だけ支払います—リクエストがなければ、料金はかかりません。

⚡ 使った分だけ支払い、隠れた費用はありません

アイドル料金はなく、シームレスなスケーラビリティを備えています。

📖 ドキュメントを探索する

🔹 Twitterでフォローしてください：@LeapcellHQ