IT英語と変数名の読み方を、チームで共有する方法

長い変数名を、意味のある単語へ分ける

userLastLoginAtを読む前に、user / last / login / atと区切ってみます。camelCaseでは大文字、snake_caseではアンダースコアが区切りを考える手掛かりになります。読みと一緒に「ユーザーの最終ログイン日時」と意味を添えると、初めてコードを見る人も会話に参加しやすくなります。

ただし、区切りは表記だけで一意に決まるとは限りません。略語を連続して使った名前や、製品固有の表記は、元の仕様や定義箇所を確認します。読みやすさを理由に公開APIの識別子を変えることは避け、まず説明を補います。

製品名・略語・一般語を分けて確認する

製品名なら開発元の公式サイトやFAQ、一般の英単語なら辞書の音声や発音表記を確認します。略語の場合は、何の略かを確かめることが先です。同じつづりでも分野によって意味が違うため、用語が登場する文脈を残します。

たとえばTypeScriptの資料を探すときは、カタカナだけでなくTypeScriptという公式表記を使うと対象を絞れます。カタカナは英語の発音を完全には表せないため、読みを一つに決めることより、同じ用語について話していると確認できることを優先します。

CodePartnerの読み方候補を、説明の補助に使う

CodePartnerには、英語のIT用語や変数名の読みを調べる機能があります。用語または識別子を入力し、表示された読みを元の英語と見比べて使います。長い識別子は、先に単語ごとの意味を確認しておくと、候補を判断しやすくなります。

候補が出ても、公式な呼び方が確認できたとは限りません。特に固有名詞や略語は開発元の情報を確認し、迷った場合は「この用語を指しています」とつづりを添えて会話します。複数の読みが使われている場合は、チーム内の呼び方と、外部で見かける表記を併記しておく方法もあります。

読みだけでなく、意味と参照先をメモする

引き継ぎ資料には、英語表記・会話で使う読み・このプロジェクトでの意味・参照先を一組にして残します。「プロフィール」という読みだけでは、顧客のデータ型なのか画面名なのかがわからなくなるためです。

次の書式をコピーして、レビューで説明に詰まった用語から埋めていくと、小さな用語集を作れます。発音が未確認ならそのまま未確認とし、推測を公式な読みとして記録しないようにします。

英語表記：
会話で使う読み：
このプロジェクトでの意味：
公式資料または定義箇所：
確認日：

• 読みと一緒に元のつづりを残したか
• 単語の発音と、識別子全体の意味を分けて確認したか
• 公式に確認できた情報と、会話のための呼び方を区別したか
• 初めて参加する人が参照先から同じ用語を探せるか

あわせて読みたいガイド