pyflakes と flake8 の紹介

以前にソースコードの静的解析を行う pylint を紹介しました。
今回は、同じくソースコードの静的解析を行う pyflakes を紹介します。


pylint の記事と同じ以下のソースコードに対して、pyflakes を走らせます。

def make_plural(fruit):
    if fruit == 'apple':
        plural = 'apples'
    elif fruit == 'orange':
        plural = 'oranges'
    elif fruits == 'peach':
        plural = 'peaches'
    else:
        prural = ''

    return plural

結果は以下のようになりました。

fruit.py:6: undefined name 'fruits'
fruit.py:9: local variable 'prural' is assigned to but never used

pylint と同じく２箇所のバグを指定してくれています。lint として十分使えるのではないかと思われます。


ここまで、pyflakes について簡単に紹介してきました。しかし、実際には pyflakes を単品で使うことは少なくて、より統合化された flake8 を使うのが一般的です。
flake8 はデフォルトでは pyflakes + pycodestyle としてチェックを行います。つまり、ソースコードの解析は pyflakes が、ソースコードのスタイルチェックは pycodestyle が行い、結果はまとめて表示されます。pyflakes と pycodestyle を別々に走らせる必要がないわけで、単純に便利ですよね。

さらに、flake8 はプラグインを導入することで、別のチェックを追加することができるようになっています。
最も有名なのは、pydocstyle を追加する flake8-docstrings でしょうか。このプラグインをインストールすると、pyflakes + pycodestyle + pydocstyle の３つのチェックを一度で行えることになります。
他にも、様々なプラグインが公開されています。

pep8 と pep257 の名前変更

以前に当ブログでも紹介した pep8 の名前が、pycodestyle に変更となりました。

Guido氏自らが「"PEP8"と言ったときに、ドキュメントの"PEP8"なのか、プログラムの"pep8"なのか、分からないのは良くない」と提議したことによります。
https://github.com/PyCQA/pycodestyle/issues/466
なお、提議の最後は、「"pep8"は素晴らしく、私も使っている。これを作らせた人も素晴らしい（※自身のこと）」とジョークを混じえ、提議の対象が名称だけであることを強調しています。

この提議の結果、pep8 は pycodestyle に名称が変更されました。
ただし、当面の互換性のため、pep8 はそのまま残り、pycodestyle というモジュールが新たに作られるという形になりました。pep8 は更新停止、今後のバージョンアップは pycodestyle のみで行われる、ということになります。


pep8 と同じ理由から、pydoc用の文字列をチェックする pep257 も、pydocstyle に変更されました。当面 pep257 は残る点、pep257 の更新が停止した点も、pep8 と同じです。

pep8でスタイルチェック

Python ソースコードのコーディングスタイルをチェックする pep8 を紹介します。

pep8 はその名の通り、ソースコードが PEP8 に準拠しているかどうかをチェックするライブラリです。
以下のソースコードを pep8 でチェックしてみます。

__version__ = '1.0.0'

import fnmatch
import os

def my_glob(root_dir='.', pattern='*', recursive=False):
    paths = []
    append = paths.append
    
    for loop_dir, _, files in os.walk(root_dir, topdown=True): # topdown shall be True
        for file in files:
            if fnmatch.fnmatch(file, pattern):
                append(os.path.join(loop_dir, file))

        if not recursive:  # if not recursive, break in first loop
            break

    return  paths

チェック結果は以下のようになりました。ソースコードの書式について、いくつか指摘が挙がっています。

3: E402 module level import not at top of file
4: E402 module level import not at top of file
6: E302 expected 2 blank lines, found 1
9: W293 blank line contains whitespace
10: E261 at least two spaces before inline comment
10: E501 line too long (86 > 79 characters)
18: E271 multiple spaces after keyword

（対訳）
3行目: E402 importは最上部に書くべき
4行目: E402 importは最上部に書くべき
6行目: E302 関数の前は２行空けるべき、１行しか空いていない
9行目: W293 空行に空白が混じっている
10行目: E261 文中のコメントは、# の前に空白を２つ以上置くべき
10行目: E501 行の文字数が多すぎる (86文字 > 79文字)
18行目: E271 returnの後ろにスペースが複数ある

pep8 の特徴として以下が挙げられます。

• 動作が軽量
• 指摘理由が PEP8 由来であるという点がハッキリしている
• あくまでコーディングスタイルのチェックであり、ソースコードの分析は行わない

ソースコードはプログラマーの成果物です。世に出す前には、このツールで形を整えておきたいところです。

pylintは是非使おう

Python ソースコードの静的解析を行う pylint を紹介します。
pylint は Python での lint の代表的な実装です。外部ライブラリであり、インストールも少々大掛かりですが、lint としての機能は十分に高いです。

以下のようなソースコードを考えます。

def make_plural(fruit):
    if fruit == 'apple':
        plural = 'apples'
    elif fruit == 'orange':
        plural = 'oranges'
    elif fruits == 'peach':
        plural = 'peaches'
    else:
        prural = ''

    return plural

この１１行の中に、タイプミスによるバグが２つあります。
C言語や Java のような静的言語であれば、このようなタイプミスはコンパイル時に見つかります。しかし、Python をはじめとする動的言語では、実行してその箇所を通った時に、初めてエラーとして表に出ます。
静的言語と動的言語の比較は簡単な問題ではありませんが、動的言語を書く場合には、このようなタイプミスが起こらないようにテストやレビューをしっかり行うことは必須となります。

では、上記のソースコードを pylint で解析してみます。

[E0602(undefined-variable), main] Undefined variable 'fruits'
[W0612(unused-variable), main] Unused variable 'prural'

２つのタイプミスが解析結果で指摘されています。
これらの指摘は、プログラム解析を行った結果として得られたものです。即ち、コードの形だけをチェックしたのではなく、中身まで分析した結果として指摘が得られています。この点は pylint の大きな強みです。

もちろん pylint の指摘が常に正しいとは限りません。また、少々口うるさく感じられる場面もあります。
それでも、ここで例に挙げたようなタイプミスによるバグを防ぐためにも、ソースコードを世に出す前には pylint で静的解析をしておくことは必須と言えます。