Day 80:コード品質 ― 「動くだけじゃなく、読みやすくて安心できるコードへ」
Day 80では、いよいよ「コードの質」というテーマに踏み込みます。
- PEP 8
- フォーマッタ
- リンター
- 型ヒント
この4つは、Pythonで開発していくうえで、 長く付き合っていく“相棒”のような存在になります。
「とりあえず動けばいい」から一歩進んで、 “人が読んでも気持ちいいコード” を目指していきましょう。
コード品質とは ― 「未来の自分と仲間のためのやさしさ」
コード品質というと、 難しい専門用語が並びそうですが、 本質はとてもシンプルです。
「後から読んだときに、理解しやすくて、壊れにくいコードかどうか」
これがコード品質です。
- 読みやすさ(スタイル・命名・コメント)
- 一貫性(人によって書き方がバラバラにならない)
- 安全性(バグやセキュリティホールを減らす)
こうした要素を支えてくれるのが、 今日の主役たち――PEP 8、フォーマッタ、リンター、型ヒントです。
PEP 8 ― 「Pythonの公式スタイルガイド」
PEP 8って何?
PEP 8は、
「Pythonのコードを読みやすく書くための公式ルールブック」
です。
ざっくりとしたポイントだけ挙げると、
- インデント:スペース4つ
- 行の長さ:だいたい79〜88文字程度に収める
- 命名規則:
- 関数・変数:
snake_case(例:total_price) - クラス:
PascalCase(例:UserProfile)
- 関数・変数:
- スペースの使い方:
- 演算子の前後にスペース
- 引数の区切りにスペース
といったルールが定められています。
PEP 8前後のコードを見てみる
PEP 8に沿っていないコードの例と、 整えた例を並べてみます。
# PEP 8に沿っていない例
def addNumbers(x,y):return x+y # ぎゅっと詰まりすぎていて読みにくい
# PEP 8に沿った例
def add_numbers(x: int, y: int) -> int:
"""x と y の合計を返します。"""
return x + y
Python- 関数名が
addNumbers→add_numbersに - 引数の間にスペース
- 改行してインデントを整える
- 型ヒントとdocstringも追加
こうすることで、 「何をする関数なのか」が一目で分かるようになります。
フォーマッタ ― 「見た目を自動で整えてくれるお掃除ロボット」
フォーマッタとは
フォーマッタ(formatter)は、
「コードの見た目(インデント・スペース・改行など)を自動で整えてくれるツール」
です。
Pythonでは、
blackautopep8yapf
などがよく使われます。
なぜフォーマッタが便利なのか
人間が手作業で、
- スペースを入れたり
- 改行位置を調整したり
していると、どうしてもミスが出ますし、 人によってスタイルがバラバラになりがちです。
フォーマッタを使うと、
- 「保存したら自動で整形」
- 「プロジェクト全体で同じスタイル」
という状態を簡単に作れます。
「スタイルの細かい違いで悩む時間をなくして、ロジックに集中する」
これがフォーマッタの大きな価値です。
blackの簡単な例
black を使った整形のイメージを見てみましょう。
# 整形前
def my_func(a,b, c): return a+b*c
x=my_func(1,2,3)
Pythonこれに black をかけると、こんな感じになります。
# 整形後(black適用後)
def my_func(a: int, b: int, c: int) -> int:
"""a, b, c を使った計算結果を返します。"""
return a + b * c
x = my_func(1, 2, 3)
Python- 引数のスペース
- インデント
- 改行
- 代入の前後のスペース
などが一気に整えられます。
ポイント:
- 「自分の好み」よりも「プロジェクト全体の統一」を優先できる
- チーム開発で特に威力を発揮する
リンター ― 「コードの中身をチェックしてくれる点検ドローン」
リンターとは
リンター(linter)は、
「コードを実行する前に、エラーや怪しい書き方を指摘してくれるツール」
です。
フォーマッタが「見た目」を整えるのに対して、 リンターは「中身」をチェックします。
Pythonでは、
flake8pylintruff
などが代表的です。
flake8のイメージ
例えば、こんなコードがあったとします。
import os # 実は使っていないインポート
def fizzbuzz(n: int) -> str:
if n % 15 == 0:
return "FizzBuzz"
elif n % 3 == 0:
return "Fizz"
elif n % 5 == 0:
return "Buzz"
else:
return str(n)
if __name__ == "__main__":
print(fizzbuzz( 1 ))
Pythonこのファイルに対して flake8 を実行すると、
- 使っていないインポート(
os) - スペースの不適切な使い方(
fizzbuzz( 1 )の中のスペース)
などを指摘してくれます。
リンターが教えてくれること
リンターは、例えばこんな点を教えてくれます。
- 未使用の変数・インポート
- PEP 8違反のスタイル
- 潜在的なバグにつながりそうな書き方
セキュリティの観点でも、
- 「使っていないけど残っている危険なコード」
- 「意図しない挙動を生みそうなロジック」
を早めに見つける助けになります。
型ヒント ― 「Pythonでも、型を“言葉”として残しておく」
型ヒントとは
型ヒント(type hints)は、
「関数の引数や戻り値に、どんな型を想定しているかを明示する仕組み」
です。
Pythonは動的型付けの言語ですが、 型ヒントを付けることで、
- 自分の意図をコードに残せる
- ツール(mypyなど)が型チェックしてくれる
というメリットが生まれます。
型ヒントの基本例
def greet(name: str, age: int) -> str:
"""
名前と年齢を受け取り、挨拶文を返します。
name: 文字列
age: 整数
戻り値: 文字列
"""
return f"こんにちは、{name}さん({age}歳)!"
Pythonname: str→ 文字列を想定age: int→ 整数を想定-> str→ 戻り値は文字列
という「約束」が、コードの中に明示されます。
mypyで型チェックする
型ヒントを活かすための代表的なツールが、
mypy
です。
インストールはシンプル。
bash
pip install mypy
型チェックはこうです。
bash
mypy your_script.py
例えば、こんなコードを書いてしまったとします。
def add(a: int, b: int) -> int:
return a + b
result = add("1", 2) # 文字列と整数を渡してしまっている
Pythonmypy を実行すると、
- 「
addはintを受け取るはずなのに、strを渡している」
というエラーを教えてくれます。
ポイント:
- 実行する前に「型のミスマッチ」を見つけられる
- 大きなプロジェクトほど、型ヒント+mypyの価値が高まる
Day 80ミニテンプレート ― コード品質セット
最後に、今日の内容をひとまとめにした 「コード品質ミニテンプレート」 を載せておきます。
1. PEP 8に沿った関数を書く
# calc.py
def add(a: int, b: int) -> int:
"""
2つの整数 a, b を足し算して返します。
"""
return a + b
def divide(a: int, b: int) -> float:
"""
2つの整数 a, b を割り算して返します。
b が 0 の場合は ZeroDivisionError を送出します。
"""
return a / b
Python2. フォーマッタ(black)を使って整形する
bash
pip install black
black calc.py # calc.py をPEP 8準拠のスタイルに整形
保存時自動整形をエディタに設定しておくと、 「書く → 保存 →勝手にきれいになる」という快適ループができます。
3. リンター(flake8)で中身をチェックする
bash
pip install flake8
flake8 calc.py
- 未使用インポート
- スタイル違反
- 潜在的なバグ
などを、コミット前にチェックする習慣をつけておくと、 コードレビューがぐっと楽になります。
4. 型ヒント+mypyで型の整合性を確認する
bash
pip install mypy
mypy calc.py
- 間違った型を渡していないか
- 戻り値の型が想定通りか
を、機械的にチェックしてくれます。
Day 80のまとめ ― 「読みやすさと安心感を、ツールとルールで手に入れる」
今日の主役は、
- PEP 8:Pythonの公式スタイルガイド
- フォーマッタ:見た目を自動で整えるツール(black / autopep8など)
- リンター:中身を静的解析してくれるツール(flake8 / ruffなど)
- 型ヒント:意図をコードに刻み、mypyなどで型チェックできる仕組み
でした。
コード品質を意識し始めると、
- 「自分のコードが、少し“作品”っぽく見えてくる」
- 「他の人に見せても恥ずかしくない形にしたくなる」
- 「未来の自分が読んでも、ちゃんと理解できる」
そんな感覚が、じわじわ育っていきます。
Day 80でこの扉を開いたことで、 これから書いていくコードは、
「動くだけじゃなく、読みやすくて、安心して育てていけるもの」
へと、少しずつ変わっていきます。
ツールとルールを味方にしながら、 自分のコードに、やさしさと誇りを少しずつ足していきましょう。

