可読性を阻害するワンライナー設計のレビュー観点

Pythonは「1行で多くを記述できる」言語である。
しかしその自由さゆえに、レビュー現場では「簡潔すぎて読めないコード」が頻繁に登場する。
特に関数のネスト、リスト内包表記、三項演算子、ラムダ式などを安易に使ったワンライナーは、意図の可視性を著しく低下させる原因となる。

本マニュアルでは、ワンライナー設計が招く読解性の問題をどう見抜き、どう改善指導すべきかを具体例を通して解説する。

典型パターン1：三項演算子の多重ネスト

多重三項演算子

status = "ok" if code == 200 else "timeout" if code == 408 else "error"

一見簡潔に見えるが、レビューでは以下のような懸念がある。

ネスト構造レビュー

@Reviewer: 三項演算子が多重化しており、読解性が低下しています。明示的な`if-elif-else`構造への展開を検討してください。

if code == 200:
    status = "ok"
elif code == 408:
    status = "timeout"
else:
    status = "error"

三項演算子とは

Pythonでは X if 条件 else Y の形式で1行の条件分岐を表現できる。
簡潔に書けるが、複数の条件を重ねると逆に読みづらくなるため、使用は限定的にすべきとされる。

ネストしたリスト内包

result = [func(x) for x in items if x > 0 if isinstance(x, int)]

複数条件を重ねることで一行に詰め込まれているが、意図と処理順が追いにくい。

内包表記レビュー

@Reviewer: 内包表記に複数の条件が重なり、処理意図が読み取りにくくなっています。filter関数や通常のfor文で明示化する構造が適しています。

filtered = filter(lambda x: x > 0 and isinstance(x, int), items)
result = [func(x) for x in filtered]

関数合成のワンライナー

names = list(map(lambda u: u.name.upper(), filter(lambda u: u.active, users)))

処理の流れが右から左に流れており、かつ匿名関数が2つという点で可読性が落ちる。

関数連鎖レビュー

@Reviewer: `filter→map`構造に匿名関数が重なり、読み手にとって負荷が高くなっています。通常のfor文への展開を検討してください。

names = []
for user in users:
    if user.active:
        names.append(user.name.upper())

ワンライナーreturn

def get_flag(x): return True if x > 0 else False

冗長ワンライナー

@Reviewer: `x > 0` はそのまま `bool` として評価できるため、三項演算子を使う必要がありません。`return x > 0` に簡略化可能です。

不明瞭な論理合成

if user and user.is_active and not user.is_banned:
    access()

if not user:
    return
if not user.is_active:
    return
if user.is_banned:
    return
access()

明示的ガード節の提案

@Reviewer: 論理式が合成されており、どの条件で失敗するかが不明瞭です。ガード節として分解すると、エラー原因の追跡が容易になります。

観点	確認ポイント	指摘判断
構造の追いやすさ	実行順序・処理意図が直感的に追えるか	✕ → 分解推奨
処理の責務が一貫しているか	複数の操作が混在していないか	✕ →関数分割検討
テスト可能性	処理をunit testで確認できる構造になっているか	✕ →切り出し
エラー発生箇所の特定	バグ発生時に原因箇所が明確に読み取れるか	✕ →構造変更

Pythonでは「簡潔さ」が強調されることが多いが、簡潔さと可読性は必ずしも一致しない。
レビューアーは、その1行が本当に読みやすく、安全で、修正しやすい構造かを評価し、必要であれば意図を明示する形への構造変換を提案することが望ましい。

「1行で書ける」は正しさの証ではない。
レビューにおける本当の価値は、「誰が読んでも間違えない構造を選べているか」である。