第6章: プログラミング英語 — エンジニアのための英語

コマンド名には必ず意味がある。語源を知ることで、コマンドの動作が直感的に理解でき、英語で説明する際の表現力が上がる。

gitコマンドの語源

commit

本来の意味

「責任を持って約束する」「決意して取り組む」。変更を確定して履歴に「約束」する。

"Are we committing to this architecture?" → これで決定するの？

push / pull

物理的な「押す」「引く」

push: ローカルをリモートへ「押し出す」
pull: リモートをローカルへ「引き込む」

"Push your code to the remote repository."

stash

「隠す・蓄える」

変更を一時的に隠して保存する。「引き出しに隠す」のイメージ。

"I'll stash my changes before switching branches."

revert

「元の状態に戻る」

変更を取り消して以前の状態に戻す。履歴は保存される。

"Let's revert this commit — it broke production."

blame

「責任を追及する・非難する」

誰がその行を書いたかを追跡する。"Who wrote this?" を調べる際に使う。

"git blame to find who introduced this bug."

cherry-pick

「選り好みする・都合のいいものだけ選ぶ」

特定のコミットだけを選んで別のブランチに適用する。

"Cherry-pick only the hotfix commit to main."

fetch

「取ってくる」（物を取りに行く動作）

リモートの情報を取得するがマージしない。pull との違いは「取得のみ」。

"Fetch the latest changes before reviewing."

rebase

「基点（base）を再設定する」

コミット履歴を別のブランチの先頭に移植する。「土台を変える」イメージ。

"Rebase on main before opening the PR."

Linuxコマンドの略語

コマンド	略語の元	意味	発音
`ls`	list	ディレクトリ一覧表示	"ell ess"
`cd`	change directory	ディレクトリ移動	"see dee"
`pwd`	print working directory	現在のパス表示	"pee double-you dee"
`chmod`	change mode	ファイルのパーミッション変更	"ch-mod"
`chown`	change owner	ファイルの所有者変更	"ch-own"
`grep`	globally search regular expression and print	パターン検索	"grep"
`awk`	Aho, Weinberger, Kernighan（作者の頭文字）	テキスト処理ツール	"awk"
`sed`	stream editor	テキスト変換	"sed"
`cat`	concatenate	ファイル結合・表示	"cat"

ソースコード系ディレクトリ略語

略語	元の言葉	意味・用途
`src`	source	ソースコード本体。編集するファイルはここ
`dist`	distribution	ビルド後の配布物。直接編集しない
`lib`	library	再利用可能なライブラリコード
`utils / util`	utilities	汎用ユーティリティ関数群
`tmp / temp`	temporary	一時ファイル置き場（.gitignoreに入れる）
`bin`	binary	実行可能ファイル（バイナリ）
`etc`	et cetera（ラテン語「など」）	その他の設定ファイル
`var`	variable	可変データ（ログ、PIDなど）
`usr`	user	ユーザープログラム・リソース
`config / conf`	configuration	設定ファイル群
`docs`	documentation	ドキュメント
`tests / spec`	tests / specification	テストコード

Conventionalなファイル名・拡張子

ファイル名	意味	役割
`index.js`	index（索引・先頭）	モジュールのエントリポイント
`main.go`	main（メイン・主）	プログラムの起動点
`README.md`	read me（私を読んで）	プロジェクトの説明書
`CHANGELOG.md`	change log	変更履歴
`.env`	environment	環境変数ファイル（コミットしない）
`Makefile`	make file	ビルドタスクの定義ファイル
`Dockerfile`	Docker file	コンテナイメージのビルド定義

/dev はコンテキストによって意味が変わる。Unixでは /dev/null などのデバイスファイル。プロジェクトでは development の略で開発環境用の設定。

エラーメッセージの読み方

メッセージ	意味	原因の例
`Connection refused`	接続が拒否された	サーバーが起動していない、ポートが閉じている
`Connection timed out`	接続がタイムアウト	ファイアウォール、ネットワーク遅延
`Connection reset by peer`	相手側から接続リセット	サーバーがクラッシュ
`Permission denied`	権限がない	sudo が必要
`No such file or directory`	ファイルが存在しない	パスが間違っている
`Segmentation fault (core dumped)`	不正なメモリアクセス	nullポインタ参照、バッファオーバーフロー
`Stack overflow`	スタックメモリ枯渇	無限再帰
`Killed`	OOM Killerによって強制終了	メモリ不足
`Rate limit exceeded`	レート制限超過	指数バックオフでリトライ
`401 Unauthorized`	認証が必要	トークンが期限切れ・未提供
`403 Forbidden`	権限はあるが禁止	アクセス制御による拒否
`404 Not Found`	リソースが見つからない	URLの間違い、リソースが削除済み

省略されたエラーメッセージの完全形

エラーメッセージはスペース節約のため主語・be動詞が省略されている。会話で伝える時は完全な文に直すと分かりやすい。

── 省略形 → 完全な文 ──
"Connection refused"  →  "The connection was refused."
"Permission denied"   →  "The permission was denied."
"File not found"      →  "The file was not found."

── 会話での伝え方 ──
"We're getting 'connection refused' errors when hitting the auth service."
"There's a 'stack overflow' in the parser — probably infinite recursion."

メソッド名は「何をするのか」を正確に伝える。動詞の選択次第で、非同期かどうか・副作用があるかどうか・成功を保証するかどうかが伝わる。

データ取得: get / fetch / retrieve

動詞	ニュアンス	例
`get`	最も汎用・軽量。同期・ローカル向き	`getFullName(user)` / `getUserById(id)`
`fetch`	外部から取りに行く（非同期・API・DB）	`fetchUserFromAPI(id)` / `fetchOrderHistory(userId)`
`retrieve`	ストレージ・永続化層から取り出す	`retrieveFromCache(key)` / `retrieveArchivedLogs(date)`

削除: delete / remove / clear / purge

動詞	ニュアンス	例
`delete`	完全削除（最も一般的）	`deleteUser(id)` / `deleteFile(path)`
`remove`	コレクション・リストからの取り除き	`removeItemFromCart(cartId, itemId)`
`clear`	中身を空にする	`clearCache()` / `clearForm()`
`erase`	痕跡ごと消去（強い）	`eraseUserData(userId)`（GDPR対応など）
`purge`	不要なものを一括削除	`purgeExpiredSessions()` / `purgeOldLogs(30)`

検証: check / validate / verify / ensure

動詞	ニュアンス	失敗時の動作
`check`	軽い確認	boolean を返す
`validate`	形式・ビジネスルールの検証	boolean またはエラーを返す
`verify`	真正性・正確性の確認	boolean を返す
`ensure`	満たされていることを保証（ガード節）	例外を投げる

真偽値を返す命名プレフィックス

isActive isLoading isEmpty hasPermission hasChildren hasError canDelete canEdit shouldRetry shouldRedirect

プレフィックス	ニュアンス	例
`is`	状態・性質（〜である）	`isAuthenticated(user)`
`has`	所持・存在（〜を持っている）	`hasAdminRole(user)`
`can`	能力・可能性（〜できる）	`canEditPost(user, post)`
`should`	推奨・期待（〜すべき）	`shouldShowOnboarding(user)`

コールバック・ライフサイクルの命名パターン

── on + イベント名: イベントハンドラー（propsで渡す名前） ──
onClick  onChange  onError  onSubmit  onSuccess  onMount

── handle + イベント: 実際の処理関数（コンポーネント内） ──
handleSubmit  handleChange  handleKeyPress  handleError

── before / after + アクション: フック ──
beforeSave(data)     afterUpdate(record)     beforeDestroy(item)

── 使い分け ──
<Form onSubmit={handleSubmit} />
  onSubmit = イベント名（props）/ handleSubmit = 実際の処理

命名に関するコードレビューコメント

"The name 'process' is too vague. What exactly is being processed?"
"'get' implies synchronous, but this is async. Use 'fetch' instead."
"Boolean variables should start with 'is', 'has', or 'can'. Consider 'isEnabled' instead of 'enabled'."
"'data' doesn't convey what kind of data. 'userData' or 'profileData' would be clearer."