from x import * の使用是非をレビューでどう伝えるか

Pythonでは、from module import * というワイルドカード構文が可能である。
しかし、この構文は可視性・可読性・保守性の観点で多くの問題を抱えており、プロジェクトレベルで使用を禁止または制限しているケースが大多数である。

本マニュアルでは、レビューアーがimport *の使用をどう評価し、指摘し、必要に応じて代替策を示す方法を具体的に解説する。

import * の問題点：レビュー時の主な指摘ポイント

ワイルドカードインポートの例

from utils.common import *

この1行で何がimportされているのかは、コード上から判別できない。
静的解析ツール・IDE補完・型ヒント機構・コード検索性など、あらゆる開発支援機能が阻害される。

リスク	内容
名前衝突	他のモジュールからimportされた関数や変数と上書き衝突する
可読性低下	定義元がわからず、関数の由来が不明確になる
静的解析ツールの無効化	mypyやpylintなどのチェック対象外になる
自動補完の不能	IDEによる補完や参照ジャンプが不能になる
テストの不透明性	モックやパッチ対象が曖昧になり、副作用を誘発する

使用例

from services.api import *
response = fetch_data()

ワイルドカードレビュー

@Reviewer: `import *` により `fetch_data` がどこから来たものか明示されておらず、コードの可視性が著しく損なわれています。使用関数を明示的に列挙するか、モジュール単位でimportしてください。

# 開発中の実験用：本番投入時は個別importに切り替える
from sample.mathlib import *

import mathlib as m

result = m.calc_score(...)

ワイルドカードimportの例外的許容

Python公式ドキュメントでは、__init__.py 内で __all__ を定義し、限定的な import * を許容する用途があるとされている。
このとき、読み手が__all__を参照することで実際のimport内容が把握できるため、明示性のある構造と見なされる。

__init__.pyでの__all__定義

__all__ = ["func_a", "func_b"]

def func_a(): ...
def func_b(): ...
def internal_func(): ...

このように制御されたimport *の設計であれば、レビュー上での容認余地がある。
ただし、それでもコード検索性・型補完性の低下を回避するには、importの明示性が望ましい。

評価項目	チェック内容	判定基準
import内容の追跡性	利用されている関数・クラスが定義元で把握可能か	不可→NG
名前衝突リスク	他モジュールと関数名のバッティング可能性	高→NG
__all__管理の有無	明示的にimport対象が限定されているか	あり→条件付き可
開発段階か本番運用か	Jupyter/デモ用途か、業務コードとしてコミットされるか	本番→NG

ガイドライン指摘

@Reviewer: ワイルドカードimportは、補完性・静的解析・ドキュメント性に悪影響を与えるため、本プロジェクトでは禁止としています。個別importへの変更をお願いします。

改善前後の比較

- from utils.common import *
+ from utils.common import validate_id, normalize_text

変更指導

@Reviewer: 使用関数を個別に列挙することで、コードの可読性と定義の追跡性が向上します。

from x import * は書く側には便利でも、読む側・保守する側にとっては負担を増やす構文である。
レビューアーは「見えていない名前空間」に潜むリスクに敏感になり、明示的・構造的なimport設計へと導く指摘を行うべきである。

このような観点で、設計レベルのimportレビューを行うことで、安全性と可読性に優れたコードベースが維持される。