Open11

命名に必要な観点を整理する

かがんかがん

自分が命名をするときにどんなことを意識しているのか整理してみる。

対象は、ファイル名、変数名、機能名、コンポーネント名、…など。
主にコード内の英語(アルファベット+数字)の名称ではあるが、それに限らない。

かがんかがん

正確性

名前が正しいか。

const number = "str";

はダメだよね、という話。
スペルミスも同様に問題がある。

かがんかがん

弁別性

近いものと区別しやすいか。

例えば date とあったとき、その文脈の中で日付と言って指すものが一意に定まるならそれでいいが、周辺のコードで開始日を扱うときも終了日を扱うときもあったりすると、それでは不十分。

-const something = (date: Date) => {};
+const something = (startDate: Date) => {};

コード中の話ではないが、「本番環境」「開発環境」のことを「本番環境」「dev環境」と呼ぶことにしている。
ワードとして揃えるなら、「本番環境」「開発環境」なのだが、漢字2文字が共通しているとパッと見区別しづらいので、あえて外している。弁別性の観点においては「あえて外す」が大事だったりする。

他にも「オンライン」「オフライン」の代わりに「リモート」「現地」と言ったりする。1文字違いだと区別しづらいので。

かがんかがん

一貫性

同じものには同じ名前がついているか。
単体では考えることができず、レポジトリ全体や、開発者がどう認識しているかまで見る必要がある。

たとえば、「記事という同じ概念を取り扱っているのに、こっちでは posts 、あっちでは articles と読んでいる」、みたいな例。同じ名前がついていないと、同じ概念であることを認識しづらくなる。

かがんかがん

直感性(?)

直感的に理解できるか。
正確性・弁別性ともかぶるかも。

長い文字列はそれだけで読みにくいので、できるだけ短く命名したい。

かがんかがん

具体・抽象の度合い

スコープが狭いなら、抽象的な名前でもOK。
スコープが広いなら、具体的な名前にしないと正しく表現できない

かがんかがん

検索しやすさ(greppability?)

リポジトリ内で検索したときに見つけやすいか。
また、Zennの記事タイトルとかだとWeb検索で見つけやすいか(ググラビリティ)

かがんかがん

整列しやすさ (sortability?)

  • PrimaryButton
  • SecondaryButton

じゃなくて、

  • ButtonPrimary
  • ButtonSecondary

にしたほうが、ファイル名順に並べたときに近くにまとまっていいよねって話。
そのため、関連するファイル名や、オブジェクトのプロパティ名は頭を揃える。


image-1
image-11
とするか
image-01
image-11
とするかもこの観点かも。

かがんかがん

それ単体で使用方法がわかる、ドキュメントのいらない命名

ミリ秒を入れるなら durationMs にしたほうがいい、みたいな話

かがんかがん

文字種・形式

  • - はダブルクリック等の単語単位の選択で区切り文字として扱われ、一方 _ は単語の一部として扱われる。これを意識しておく。
    • どっちでもいいけど、ひと単語として選択できたほうが楽だなーというときは _ を使う
  • ファイル名・パス名に大文字を使うと不具合の原因になりやすいので、極力小文字のみで構成する
    • 特にGitでの扱いがややこしい
    • 他にも、「ローカルサーバーでは大文字・小文字関係なく読み込めていたが、本番サーバーの設定ではケースセンシティブだったのでアクセスできなくなる」という事例を経験したことがある。
    • ただ、Reactコンポーネントのファイル・ディレクトリはコンポーネント名に合わせたいのでアッパーキャメルにしてしまっている…
かがんかがん

実装を説明せず、意図を示す

例えば、「有効期限が3ヶ月」みたいのがあるとして、この有効期限の日付を取得する関数の名前をつけるとする。
ここで getThreeMonthsLater などとつけるのではなく、 getExpiredDate とつける。

  • 前者は内部実装を説明してしまっており、結局それで何がしたいかわからない。後者は目的を示しているためわかりやすい
  • 別の処理に対しても、たまたま3ヶ月という期間が同じというだけで使われてしまうかもしれない。
  • 今後、有効期限を変更したくなるかもしれず、その場合関数名も変える必要が出てきてしまう(変えなかったとしたら大混乱の元)。

他にも、 And は極力使わない、というのもある。
例えば「記事のデータを取得して、その著者情報も合わせて取得する」みたいなとき(かつ、getPost というのはすでにあってそれとは区別したいようなとき)。
getPostAndAuthor としてしまうと、後から「やっぱりコメントも取得したい」とかなったら getPostAndAuthorAndComments になってしまう。
getPostWithDetails とか、やや抽象的な名前にする。