来月の自分に怒られない名前の付け方を考えてみよう / better naming on programming

来月の自分に怒られない名前の付け方を考えてみよう ……というご提案 PHPカンファレンス仙台2019 今野夕貴(@thatblue_plus)

(このあとの話題にも繋がるので) とりあえず自己紹介だいたい仙台出身、ほぼ仙台在住学生時代を過ごした会津若松は第二の故郷新卒から10年くらいソフトウェアエンジニア的なお仕事をしています PHPer歴は通算で7年ちょい前職(2012年末〜)くらいからソシャゲやスマホゲームのバックエンドを作るお仕事
をしていますここ2〜3年はフレームワーク選定から運用まで作る部分はわりと何でもやってる気がするガルパン大好きなんですが近くにあんまり語り合える人がいないのでお友達になってください

仕事のコードでは名前の付け方について褒められることが一番多いので今日はその辺の話をしようと思います決して他に褒めるところがない、と言う話ではないと信じたいお年頃

過去の自分が書いたコードに対して怒りたくなることはありませんか当時ベストを尽くしているなら、それ自体は成長の証です誇りましょう

経験則として「先週の自分は他人と思え」とよく言われますが先週の自分にキレるのは大体ロジックがゴチャついているとき ※個人の感想です

「なんでこんな名前つけたんだ！」ってキレるのは大体先月の自分に対して一通り作りきって、文脈に対する理解が深まってるのも大きい

プログラムの書き方に関する一般的な注意点については「リーダブルコード」という名著があります https://www.oreilly.co.jp/books/9784873115658/

リーダブルコードではあまり触れられてない(と思う) あたりを中心に

来月の自分に怒られないための本日のトピック呼称が実態と離れがちな問題抽象レベルのコントロールが難しい問題英語が難しい問題

呼称と実態が離れがちな問題ゲーム案件だと特に顕著に感じます

例:スプラトゥーン「イカ」を操作して遊ぶゲームであることはご存知の方も多いはず Splatoon公式サイトより

ゲーム開発中にありがちなこと: オブジェクトのモチーフが変わる参考:社長が訊く『Splatoon（スプラトゥーン）』 https://www.nintendo.co.jp/wiiu/interview/agmj/vol1/index.html Splatoon公式サイトより

モチーフをそのまま名前に組み込むと何が起こるのか初めに操作キャラクターに関するオブジェクトに「Tofu」と付けてしまうと、モチーフ変遷の経緯を知らないとコードが読めなくなる都度リファクタするのもちょっと勇気がいる途中の「ウサギ」のモチーフに依存する命名が混ざるともう地獄操作キャラクターが「イカ」に確定したあと、別の文脈でウサギや豆腐のモチーフが出現するとさらに混
乱する ※私は任天堂関係者ではないのであくまで「こういうことが起こるかも」という想像の話です

似たようなことはいろんなところで起きている

既に出来上がった版権ベースのモチーフなら大丈夫なのでは？コンテンツの根幹になるようなモチーフに関しては確かにそうなのですが……

ベースの世界観があっても「絶対」はあんまりない「猫アニメのゲーム化で猫の代わりに戦車が出てきたりしないよね」という程度の話でしかない文脈によってはこれすらありうるのがまた…… アイテムなど、細かいモチーフが変わることは普通に発生するコインがチケットになったりなんとか石になったりするので、安易に「xxCoin」と付けられない逆に、「一旦ボツになったモチーフが別の文脈で再登場
する」というパターンが起こりがちでもある

対策:そのオブジェクトの本質は何なのかを考えるスプラトゥーンのイカの例なら「Player」等とすれば解決する操作キャラクターがタコになっても問題なし！そのオブジェクトは何をするものなのか、目的を考える目的が違うなら、同じ挙動でも一緒にしてはいけないのが難しいところ本当は目的が一緒で共通化できるのに、具体的すぎる名前に引っ張られて機能を分けないといけなくなる例もあります
ある程度強引さも必要

そして考えをこじらせた結果……

抽象レベルのコントロールが難しい問題抽象度上げすぎると読みづらい、具体的にしすぎると変更に弱い

例:「アプリ内通貨」をどう命名するか

どうやらこれはやりすぎだったらしいケース最初の時点ではモチーフが曖昧だったので、そのまま素直に「app currency(アプリ内通貨)」として実装した、が…… 多分後でリファクタした(はず) この時は悩んでいる間にモチーフが確定したので、その名前を使った正直、モチーフの具体名以外でこれよりスマートな
名前をつけろと言われても今のところ良い案は出ていません

対策:とことん抽象的に設計してとことん具体的に命名する既に世の中にあるものをメタファーとして使う例えば、世界観に合わせて「召喚」とか「スカウト」という名前であっても、「ゲーム内通貨を消費してリソースの使用権をランダムに獲得する機能」は実装上「ガチャ」って呼んでいいと思う既存の仕組みやデザインパターンに当てはまるものがあるかもしれない有名どころはGoFのデザインパターン DDDとか勉強するといいかもしれない
自分が作ろうとしているアプリケーションに対するそれなりの理解が必要どうしても端的な表現が出てこない場合、設計がおかしいことも疑ってみる

それを乗り越えた先に訪れる……

英語が難しい問題つらい

例:EC系サイトで見かけた (商品の振る舞いに対して) 「unsell」という変数名 un-(否定の接頭辞)+sell(売る)で「売れない」としたかったのは分かったのですが……

unsellがなぜダメなのか「unsell」という英単語は存在しますが、意味は「〔真実性・価値などについて人に〕信じないように説得する」というもの「unsellable」の略、という最大限好意的な解釈をしても「〔商品などが〕売れない、買い手がつかない」なので、意味が変わってしまうそもそもそういう判断をEC系のサービスで求められることはあまりないいずれにせよ、「理由がよく分からないけど購入できちゃダメなんだろうな」程度の情報しか得られない「購入ボタンを表示させない」という目的で使う変数ならこの情報
量でも問題ないですが、そもそも単語自体が誤っているのは大問題日本語で言うところの「仕様のため休みます」みたいな混乱を招く ※英単語の訳はいずれも英辞郎 on the WEBより

代わりになる名前を考えてみる購入できない: not available  非売品である: not for sale レンタル専用品である:
for rental 出品準備ができていない: not ready 在庫切れ: out of stock

例2: row(行)とraw(未加工の)と low(低い)とlaw(法律)がごっちゃになる問題カタカナ英語にすると全部「ロー」

もしrawLawRow(未加工の法律の行) なんて変数があったら正しく覚えられる気がしません…… IDEの補完機能万歳

対策:とにかく辞書を引きましょう英語圏の人でも間違えることがある(例:HTTP referer)ので、ノンネイティブな我々日本人が間違えないワケがないと思って辞書を引く英和/和英辞典はスペースアルクの英辞郎 on the WEBがお勧めです ProLite(無料)に登録すると用例検索もできます
同じような単語のニュアンスの違いは用例を見ると分かることが多いです専門用語以外はなるべく難易度の低い単語を選ぶのもポイント英検2級(高校卒業レベル)前後くらいが目安でしょうかこれもオンラインの英和辞典を引くと「レベル」として書いてありますローカルなチームであれば、いっそ日本語(ローマ字)で付けてしまうのも手私はよく「omake」って付けたりします

使う表現を決める時英和/和英辞典以外に参照しているもの類語辞典(国語・英語ともに) 英英辞典 Wikipedia 日本語ページを表示したあと、「他言語版」のリンクから英語版に飛ぶ用例確認にも使えます多言語展開しているゲームの攻略Wiki、ニコニコ大百科、ピクシブ百科事典など
Google画像検索使いたい表現で検索してイメージ通りの結果が出るかを確認する https://qiita.com/jnchito/items/3815a755b889b64a1840 から頂いた知恵

国語・英語ともに語彙力を試されるなぁって感じることが多いです

来月の自分に怒られないための本日のまとめ呼称が実態と離れがちな問題  →オブジェクトの本質と目的を考えよう！抽象レベルのコントロールが難しい問題  →とことん抽象的に設計して、とことん具体的に命名しよう！英語が難しい問題  →とにかく辞書を引こう！

目指せ、来月の自分に褒められる名付け！

来月の自分に怒られない名前の付け方を考えてみよう / better naming on pro...