この記事を書いた背景
以前、文科省が公開した教員研修用のPython教材が話題になったことがある。コードの品質についてさまざまな指摘が出ていた件だ。
内容を見ていて気になったのは、指摘されていた問題のいくつかが「初心者あるある」で終わる話ではないという点だった。「動くコードは書けるが、Pythonicな書き方ができているか」という観点は、ある程度書けるようになってからこそ意識しにくくなる。自分の書き方を見直すいい機会だと思ったので、気になったポイントを整理しておく。
組み込み関数名を変数名に使っていた
最初に目が止まったのがこれだった。
# 問題のある書き方
sum = 0
sum = a[3] + a[7]
print(sum)
sum はPythonの組み込み関数だ。上書きしてしまうと、それ以降のスコープで sum() が使えなくなる。コードが短いうちは気づきにくいが、規模が大きくなるほど原因不明の挙動につながりやすい。
# 修正後
values = [56, 3, 62, 17, 87, 22, 36, 83, 21, 12]
sum_val = values[3] + values[7]
print(sum_val)
list や dict、id、type なども同様に上書きできてしまう。変数名を決めるとき、組み込み関数と被っていないか一瞬確認する習慣を持っておきたい。
range(0, 10, 1) と書いていたところを見直した
# 冗長な書き方
for i in range(0, 10, 1):
sum = sum + a[i]
range(0, 10, 1) は range(10) と等価だ。デフォルト引数が0と1なので、省略できる。意味のない引数を明示することで、かえって読み手の注意を引いてしまう。
さらに言えば、インデックスを使ってリストを走査するより、要素を直接取り出す書き方の方がPythonicだ。
values = [56, 3, 62, 17, 87, 22, 36, 83, 21, 12]
sum_val = 0
for v in values:
sum_val += v
print(sum_val)
そしてこの処理なら sum() を使えばそれだけで済む。
sum_val = sum(values)
組み込み関数を知らずにループで代替実装してしまうパターンは、書いている最中には気づきにくい。
int((i + j) / 2) と (i + j) // 2 の違い
二分探索の実装でこういう書き方を見た。
m = int((i + j) / 2)
Python3には整数除算演算子 // がある。int() でキャストするより意図が明確で、浮動小数点を経由しないぶん厳密でもある。
mid = (bottom + top) // 2
余談だが、この部分を見て「Pythonのバージョンを意識して書いているか」という問いが頭に浮かんだ。Python2では / が整数同士の場合に整数除算をしていたが、Python3では浮動小数点除算になる。移行期に書かれたコードにこういう書き方が残っている場合があるので、古いコードを読むときは気をつけておきたい。
変数名に意味を持たせることの重要性
def binsearch(a, p):
i = 0
j = len(a) - 1
a p i j では、コードを読む人（未来の自分も含む）が文脈を把握するのに余計な認知コストがかかる。
def binary_search(values: list[int], target: int) -> bool:
bottom = 0
top = len(values) - 1
変数名を意味のある言葉にするだけで、コメントなしでも処理の意図が伝わるようになる。型アノテーションも合わせて書いておくと、エディタの補完も効きやすくなって開発体験が上がる。
スタイルの話：PEP8は一度ちゃんと読む価値がある
コメントの前のスペース、演算子の前後のスペース、インデントの幅。これらは好みの問題ではなく、PEP8というPythonの公式スタイルガイドで定められている。
-
x=1ではなくx = 1（演算子前後にスペース） -
#コメントではなく# コメント（#の後にスペース1つ） - インデントはスペース4つ
ツールに頼るのが現実的で、flake8 や ruff を導入すればこうした指摘を自動で検出できる。チームで書くなら最初にCIに組み込んでしまうのが早い。
整理して気づいたこと
「動くコードを書ける」から「読まれることを意識したコードを書ける」に移行するためのポイントは、実は細かい積み重ねで構成されている。
今回見直せたのは、組み込み関数の上書き、range の使い方、整数除算、変数名のつけ方、スタイルの基本あたりだ。
まだ自分の中で曖昧さが残っているのは、型アノテーションの適切な粒度だ。どこまで書くべきで、どこは省略してよいかの判断基準を、もう少し言語化できるようにしておきたい。
この記事を書いた人について
株式会社Flexibilityでエンジニアをしています。
DX推進・システム開発を軸に、エンジニアが自律的に動ける環境を大事にしている会社です。
技術的に面白いことをやっていきたい方や、働き方に柔軟さを求めている方は、
よかったら一度のぞいてみてください。
- 会社サイト: https://www.flexi-inc.com/
- Qiita Organization: https://qiita.com/organizations/flexi-inc