別名の乱用を避ける -- ソースコードレビューで最近指摘したこと
プログラムのソースコードレビューで私がよく指摘することをまとめようと思い、とりあえず直近のレビューフィードバックの内容を振り返ってみるメモの第2段です。
前回
今回のメモ
Pythonでの話です。
import ... as ... の構文で別名を乱用を避けます。
import ... as ... を使う場面は以下のケースに限られます。
○ コーディングスタイルの統一
プロジェクト内で一貫した命名規則を維持するために別名を使うことがあります。
特定のライブラリを常に同じ別名でインポートすることで、チーム全体でコードの一貫性を保つことができます。
import datetime as dt
import numpy as np
import pandas as pd○ 名前の衝突を避ける
同じ名前のクラスやモジュールが複数存在する場合に、名前の衝突を避けるために別名を使います。
from module1 import MyClass as MyClass1
from module2 import MyClass as MyClass2ただし、このパターンは元のクラス名を変えられず別名に頼らざるを得ない状況に限られます。同じチームの中でメンテナンスしているソースコードの中で名前が重複している場合は、別名ではなく元のクラス名を適切な名前に変えるべきです。
逆に以下のパターンは避けることと考えています。
× 長い名前を短くする
同じチームの中でメンテナンスしているソースコードの中で定義しているクラスをimportする際に名前が長いという理由だけで別名にするのは避けます。
from module1 import SomeVeryLongClassName as SomeClass元のクラス名を適切な名前に変えるか、長い名前が適切ならばその名前のまま呼び出します。いまどきの開発環境は画面が広いですし、コード補完で長い名前の入力も苦ではありませんので、文字数の節約に可読性を犠牲にする必要はありません。
別名とは違いますが、似たパターンで以下のパターンも私はコードレビューでよくないパターンとして指摘します。
class SomeVeryLongClassName:
...
SomeClass = SomeVeryLongClassNameSomeClass を呼び出している箇所から SomeClass の定義を探すときに定義の段階が増えてしまうデメリットがあるだけで、メリットが感じられません。
最初に SomeClass という名前で実装したあとで SomeVeryLongClassName に名前を変えたくなったとき、あるいは逆のときに名前を全部置き換えるのが怖いというのは理由になりません。置換すればよいだけです。あとからの保守性のほうが重要です。