未経験からエンジニアとして転職した筆者の備忘録、また知識の整理のため記事を書きます。
今回は入社してこれまで幾度となくご指摘いただいてきた命名について、アドバイスいただいたこと、本を読んで得たことをまとめます。
命名が大切な理由
意図や目的を表現した命名をすることで、コードの理解がスムーズになります。
チームのメンバーはもちろん、数ヶ月後の自分が再度コードを読む時にも可読性が上がります。
この記事を書くにあたりプログラミングを学び始めのころの自分のコードを見てみましたが、以下のNGパターンのオンパレードで読むのが大変でした。。
命名NGパターン
意図がわからない名前は避ける
-
技術駆動命名
プログラミング用語やコンピューター用語（例:
Int,Memory,Flag）に基づいた命名。意図が伝わりにくい
-
連番命名
例:
user1,user2のように番号で区別。中身の違いが伝わらない。
-
tmpの多用
一時的にしか使わない前提の名前。実際は長生きしやすく、後で混乱を招く。
-
ロジックと名前のズレ
命名から意図が読み取れないと、実装との対応が崩れる。名前を見直すか、メソッドやクラスを分割する必要がある
-
ロジック構造をなぞった命名
「forを回して〇〇をフィルターして〇〇をマージする」のように処理手順をそのまま書くと冗長になりやすい。
// NG
function filterAndSortAndMerge(items: Item[]): Item[] {
// ...
}
// OK
function getAvailableProducts(items: Item[]): Item[] {
// 処理の意図（何を得たいのか）が名前から分かる
}
改善のポイント
省略しない
-
usrよりuserのように、できるだけ省略せず明示的に。
目的ごとに変数を用意する
- 再代入せず、変数の用途を一貫させる。
- コード途中で変数の意味が変わるとバグを生みやすい。
// NG
let product = getReservedProduct();
product = getOrderedProduct(); // 意図が変わってしまう
// OK
const reservedProduct = getReservedProduct();
const orderedProduct = getOrderedProduct();
単一責任を意識する
- 責務ごとに分割し、可能な限り具体的で意味範囲が狭い命名にする
- 意味範囲の広い命名になると多くの責務を抱え「神クラス」化する
マジックナンバーを避ける
その数値が何を表しているのか、なぜその値が選ばれたのかが不明確なマジックナンバーは意味のある名前（シンボル）を付けるようにする。
// 例
const TAX_RATE = 0.08
その他Tips
その他、本には「声に出して話してみるといい」とも書いてありました。
- 目的・用途・関係を説明することで背景を整理できる
- チームに共有すれば方向性のズレも早期に気づける
- 独り言でも発することで自ら原因や違和感に気づき自己解決できる
これは言語化に苦手意識がある私の今後の課題になると思っています。
さいごに
今回、命名の基本中の基本をまとめましたが、まだまだ意識すべきことはあると思います。さらなる知識をつけ、コード理解を助けるような良い名前をつけられるエンジニアを目指していきたいと思います！