皆さまこんにちは、ウチイダです。

時間を見つけてはDjango で中規模以上のアプリケーションを開発するための環境構築について調べています。

前回の記事はこちら。

ウチイダの作業環境は以下です。

• Windows 11 21H2
• WSL2 Ubuntu20.04
• GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

以降の内容は、この環境にPython/Djangoの開発環境を導入していく手順メモとなります。

PEP 8 遵守はFlake8 におまかせ

さて、前回も述べたとおりですが、コーディングルールを決めたり、目視・手動でルールを順守するのはとても大変です。プログラムを書くときは、ロジックの実装のことだけ考えていたいものです。

PythonにはPEP 8というデファクトスタンダードなスタイルガイドがありますので、これにきっちり合わせていきたいです。

書いたプログラムがPEP 8 のルールに沿っていない場合に教えてくれるのが、Flake8 です。

厳密には、コードチェックのためのいくつかのパッケージを含んでいますが、今回はPEP 8のチェックのために利用します。

パッケージのインストール

過去の記事に続いて、poetry でインストールしていきます。

(python-flake8-sample-py3.11) $ poetry add --dev flake8
Creating virtualenv flake8-sample in /home/y-uchiida/python/flake8_sample/.venv
The --dev option is deprecated, use the `--group dev` notation instead.
Using version ^6.0.0 for flake8

Updating dependencies
Resolving dependencies... (0.2s)

Writing lock file

Package operations: 4 installs, 0 updates, 0 removals

  • Installing mccabe (0.7.0)
  • Installing pycodestyle (2.10.0)
  • Installing pyflakes (3.0.1)
  • Installing flake8 (6.0.0)

CLI から実行する

それではFlake8 を使ってみます。

flake8 <チェック対象のファイルパス> で実行できます。

PEP 8に沿ってない内容のスクリプトを書いて、、、

if 1 is 1:  # リテラルの比較に is は使わない
  print('always true')  # インデントはスペース4つにする

Flake8 で検査します。

(python-flake8-sample-py3.11) $ flake8 flake8_test.py
flake8_test.py:1:4: F632 use ==/!= to compare constant literals (str, bytes, int, float, tuple)
flake8_test.py:2:3: E111 indentation is not a multiple of 4

しっかりエラーを出してくれました！

Flake8 はチェックツールなので、自動での修正はしてくれません。列挙された内容を見て、それぞれ必要な修正をしていきましょう。

VSCode のFlake8 拡張

とはいえ、CLIでコマンドを実行して、それを確認しながら修正するのは大変です。

コードを記述している段階で、エディタ上にエラーが出てくる方が簡単です。

というわけで、VSCodeに拡張機能を導入していきます。

Microsoft が提供している拡張機能があるので、これを利用します。

拡張機能の説明文によると、この拡張機能を導入するだけで、Flake8でのコードチェックが使えるようになるみたいです。

プロジェクトで選択されているPython環境にFlake8 がインストールされていない場合だけ、拡張機能がバンドルしているflake8 (5.0.4)が利用されるとのこと。

CIで利用するにはパッケージを入れておく必要がありますが、書き捨てのちょっとしたプロジェクトなら、拡張機能を入れておくだけでいいかもしれません。

まあ、そういう場合はそもそもコードチェックツール使う必要もないのかもしれませんが…

設定値の変更

念のため、VSCode でFlake8がしっかり動作するように、設定を変更していきます。

まずはデフォルトのリンターを変更します。

デフォルトでPylint が有効になっているので、これを無効にしておきます。

VSCode の設定をひらいて、python.linting.pylintEnabled のチェックを外します。

代わりに、Flake8 を有効にします。

python.linting.Flake8 Enabled にチェックをつけます。

これで、基本的にはOKです。

こんな感じで、エディタ上とProblemsパネルにスタイル違反を表示してくれます。

これで、問題のあるコードがすぐにわかります。

Blackとの併用の設定

さて、ここまででFlake8 の設定自体は終わりです。

しかし、「妥協を許さないフォーマッター」ことBlackと併用する場合、ルールの食い違いが起こってしまいます。

Black はルールの変更ができないので、Flake8 のルールを変更してあげる必要があります。

Black のドキュメントに対応方法が書いてあるので、それに従えばOKです。

https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html

設定ファイルとして.flake8 か、setup.cfg か、tox.ini を用意して、以下のように記述します。

すでに上記のファイルがある場合は、追記してください。

[flake8]
max-line-length = 88
extend-ignore = E203

残念ながらFlake8 はpyproject.toml の設定情報を読んでくれません。

pyproject-flake8 という、Flake8 のラッパーを導入することでpyproject.toml に設定を書くことができるようです。

.flake8 ファイルを使えば、Flake8 の設定ファイルであることが一目瞭然なので、あえてこのままでもいいのでは、と考えています。

ちなみに、上記の設定例ではmax-line-length が88になっていますが、1行88文字は意外と短いです。

Blackでも唯一変更できるルールなので、設定値を100とか120に変更する場合もあると思います。

その場合は、Flake8のほうもその設定に合わせておきましょう。

まとめ

PEP8 のさまざまなルールを瞬時にチェックしてくれるFlake8のご紹介でした。

コードスタイルの乱れは風紀の乱れ、ということで、勝手に風紀委員と思っています。

Flake8 には、maccabe というコードの複雑度を判定するパッケージも含まれています。

これも使ってみたいところですが、運用方法がややこしくなりそうなので、今のところは見送っています。

以上です。あなたのお役に立てると嬉しいです。

参考資料

https://qiita.com/fehde/items/723b619013dc86008acc

https://itc-engineering-blog.netlify.app/blogs/black-flake8

皆さまこんにちは、ウチイダです。

時間を見つけてはDjango で中規模以上のアプリケーションを開発するための環境構築について調べています。

前回の記事はこちら。

ウチイダの作業環境は以下です。

• Windows 11 21H2
• WSL2 Ubuntu20.04
• GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

以降の内容は、この環境にPython/Djangoの開発環境を導入していく手順メモとなります。

Blackで、フォーマッターの下の平等を実現する

コードスタイルの一貫性を保つのは、読みやすさを維持するために重要です。でも、コーディングルールをきちんと決めるのがまず大変だったりします。

また、コーディングルールを気にかけながらコードを書くのはつらいです。

こういうのはツールに頼ってしまいたい部分ですね。

今回はBlack を利用して、自動フォーマットをかけるところまでやってみたいと思います。

パッケージの導入

過去の記事に続いて、poetry でインストールしていきます。

$ poetry add --dev black
Creating virtualenv python-black-sample in /home/y-uchiida/develop/python-black-sample/.venv
The --dev option is deprecated, use the `--group dev` notation instead.
Using version ^23.1.0 for black

Updating dependencies
Resolving dependencies... (0.5s)

Writing lock file

Package operations: 6 installs, 0 updates, 0 removals

  • Installing click (8.1.3)
  • Installing mypy-extensions (1.0.0)
  • Installing packaging (23.0)
  • Installing pathspec (0.11.0)
  • Installing platformdirs (3.1.0)
  • Installing black (23.1.0)

これだけでセットアップ完了です！

CLIから実行する

black <修正対象のファイルパス> で、自動フォーマットを実行できます。

こんな感じで、みるからにガタガタなファイルを作って…

def main():	
      print("this"      +      "is"      +      'main')
      return            0

コマンドを実行！

(python-black-sample-py3.11) $ black format_test.py 
reformatted format_test.py

All done!   
1 file reformatted.

以下のように修正されました。

def main():
    print("this" + "is" + "main")
    return 0

Black の特徴

基本的な使い方がわかったところで、Black について知っておきましょう。

Blackは、ルールがとても厳格というか、選択の余地がないフォーマッターです。

ドキュメントの冒頭で、こんなことを書いています。

By using Black, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

https://black.readthedocs.io/en/stable/

ざっくり意訳すると、Blackが提供するコードスタイルに従うことで、手作業でのフォーマットや、書式設定をしなくてよくなるよ！ということです。

コードスタイルにこだわりがある人はとっつきづらいかもしれませんが、チーム開発では自動で統一されるメリットは大きいですね。

ちなみに、設定ファイルでデフォルトから変更できるルールは、2023年3月時点では1行あたりの文字数だけです。

公式リポジトリのpyproject.toml にも、それしか設定項目がありません。

https://github.com/psf/black/blob/main/pyproject.toml

「妥協を許さないフォーマッター」というだけのことはあります。

VSCode のBlack 拡張機能

次はVSCodeでBlackを利用する場合の設定手順です。

設定といっても、拡張機能をインストールするだけでした。

Black のパッケージをインストールしていなくても、この拡張機能を有効にすればOKです。

preview ってついているのが若干気になりますが、基本的な動作には問題なさそうでした。

拡張機能を入れただけだと、Blackのルールでフォーマットされないので、少しだけ設定を編集します。

@lang:python defaultFormatter で検索すると表示される項目を、Black Formatter に指定します。

また、 python.formatting.provider のデフォルトがautopep8 になっているので、 black を指定しておきます。

また、ファイルの保存時にblack でフォーマットがかかるように、Format On Saveの設定も有効にしておきます。

これで、VSCodeの設定は完了です！

スペースがガタガタなファイルを、VSCode で保存してみると、きっちりそろえてくれます

まとめ

導入するだけですぐに使えるフォーマッター、Blackのご紹介でした。

コードスタイル疲れのない、快適なPythonライフを送れそうです。

OSSでの利用数もすごく増えているようで、Blackに慣れておくといろいろなPython のコードが読みやすくなるかもしれません。

以上です。あなたのお役に立てると嬉しいです。

参考資料

https://nobunobu1717.site/?p=1845

https://nujust.hatenablog.com/entry/2022/07/24/114715