「命名」の記事 - Crieit

【プログラミング全般】「登録する」の意でregistと書くことの是非について

2021-05-12T21:20:27+09:00

はじめに

「登録する」という意味でregistと書くのがあるあるなのかは分かりませんが、色んなプロジェクトで色んな人が書いたコードを見ても、結構registが使われていました。

英語的には誤りであり、registという単語は存在しません。正しくはregisterです。ではなぜregisterではなくregistが使われているのか、そう書いた人ひとりひとりを捕まえて「あなたはなぜregiterではなくregistと書いたのですか？」とインタビューすることはできないので、勝手に推測しています。

registerではなくregistを使う理由を推測

-erが動詞っぽくないから

個人的には一番それっぽい理由だと思います。

registerはまぎれもなく動詞なのですが、-erという接尾辞が「～する人」ということを表すので、-erを抜いたregistが「登録する」ということなのだろう、と思ったのではないかということですね。まぁ分からなくはないですが、辞書引こうよ…とは思いますね。

慣習になっているから

自分たちが手をつける以前のソースコードでびっしりとregistが使われており、registerを使いたいけど統一感なくなるのも気持ち悪いので、いやいやregistを使っているパターンですね。

短い方がいいから

registerという語であることは知っているけど、registの方が短いしチーム内で意味も伝わるからregistにしているパターン。これもなくはないでしょうし、ベテランエンジニアがこんな感じで書いてたら他のメンバーも合わせざるを得ないみたいな感じになりそうです。

insert→ins、update→updみたいに省略してもある程度意味が伝わるので、わざわざregisterと書く必要はないじゃんという発想かもしれません。

おそらく上記のような理由があるのではないかと思います。

ググってみる

「登録する regist プログラマ」みたいなキーワードでググってみたところ、以下の記事がヒットしました。

「登録する」の罠: registは間違い、アクセントにも注意

registerではなんとなく動詞らしく見えないので、こういう勘違いが発生してしまうのでしょう。

「動詞っぽくないから説」を提唱されています。私もそう思います。ちょっとややこしい単語ではありますよね。

この記事へ反応する形で、次のような記事もありました。

正確さよりも意図が“素早く正確に伝わる”ことが重要 - 2011年09月05日

プログラマやＳＥにとって、この単語が正しい英語かなんてどうでもいいことだ。さらに発音なんてさらにどうでもいいことだ。重要なことは、この単語を見た人間（おそらく同じプログラマかＳＥか）が、この単語が付いた機能なりファイルなりの概要を名前から安易にかつ正確に想像できるか？という点にある。

これに関しては半分同意といいう感じです。発音に関しては個人的にはどうでもいいと思います。それは私の周りにもネイティブの英語話者がいないからかもしれないですが、コードレビューしていて「このトライアップロードメソッドは何をしているの？」みたいにカタカナ英語で言いますし双方通じています。

ネーミングから容易に処理が分かるかというのも大事な視点です。

たとえば、認証という単語はrecognitionやcertificationを使うのが妥当だと思われる。しかしrecognitionやcertificationという単語はあまり馴染みが無い。意味を調べるのに辞書を要する人間も多いだろう。さらに文字数も多すぎる。それを考慮して、俺は認証をする機能にはauthという略語（造語？）を良く使う。

これに関しても同意できます。一方、英語の細かいニュアンスの違いを命名に落とし込んであると、より良いコードだなと思うこともあります。たとえば

beginとstartの違い
deleteとremoveの違い
sinceとfromの違い

などがコードリーディングを助けることもあるでしょう。

例として挙げられているものでも、たとえばrecognitionだと「一度認識しているものを改めて認識する」ようなニュアンスの認証ですし(接頭辞re-が付いていますね)、certificationだと「何かを申請して、それが他の誰かに承認される」ようなニュアンスの認証、auth(authentication)だとIDとパスワードを使って認証(本人確認)するようなニュアンスの認証です¹。これらのニュアンスの違いがあるのに、認証は全部authでいいや！というのはちょっとどうかと個人的には思います。

英語はやっぱり大事

そういう意味では、「正しい英語」というのはニュアンスの違いなどの理解が及ぶ範囲であれば、それは重要だと個人的には思います。ただ、registとregisterに関してはニュアンスの違いとかではなくそもそも存在しない語と存在する語の違いなので、ここでは若干違う話題ではありますが。

また、プログラミングはだいたい英語を使うため、正しい英語の重要性みたいなのを理解していないとトンチンカンなコードを書いたりします。一度directoryPassみたいな変数を見たことがあります(おそらく書きたかったのはdirectoryPath)。pathは結構頻出基礎的な単語だと思うのですが、自分より何年も長くコードを書いているような人が間違えていると、ある程度正しい英語を使うクセ付けというか、そういうのは大事だよなぁとも思います。少なくとも分からなかったらググる、あまりにも長くなりそうだったらローマ字で書くとかが「正確に伝わる」という意味ではアリだと思います。ローマ字の是非はまた議論が別れそうですが、個人的にはpathをpassと書かれるくらいならpasuと書いてもらった方が…いやpathくらい覚えてほしいな、やっぱ。

個人的にはregistだろうがregisterだろうが意味は伝わるので、既にregistが使われているプロジェクトではregistを使います。でも自分が0から作るならregisterを使います。IDEの補完機能などを使えば2文字増えようが関係ないですし、逆に2文字をケチって「あれｗこの人registっていう英単語はないって知らないのかな？ぷっぷくぷーｗ」と思われるくらいならしっかり書きます²。まぁ思われても別にいいですけど。

結局は環境次第ということだと思います。メリットデメリットあるので、ある程度クローズドな環境であればregistでもいいんじゃない？とは思いますね。ただ、世界中に公開するようなコードを書くのであればregisterを使っていた方が無難だとは思います。少し紹介しましたが、insert→ins、update→updで伝わるのになんでregistはダメなんだ！と思われたら、中途半端に略してて気持ち悪いからだと思います。中途半端にerだけ省略しても誰も幸せにならないのでregくらいまで省略すれないいんじゃないですかね？regだったら省略しているということが明かなので。registだと若干ひっかかるというか、気持ち悪い感は否めないです。個人的に。

私の理解が正しいかはわからないので鵜呑みにしないでくださいね。 ↩︎
私がregist派のみなさんをそのように思っているという訳ではないですよ。 ↩︎

【C#】命名って大事だね

2021-01-09T22:31:27+09:00

命名って大事だよね、ということはコードを書く人であればだいたい同意していただけると思う。

というかコードを書かない人も「memo.txt」と「〇月〇日までに買う予定リスト.txt」だったら、ファイルの内容が同じでも後者の方が圧倒的にわかりやすいとは思っていただけると思う。

毎度毎度弊社の困ったちゃんのことを書くのは忍びないが、だけど書くが、困ったちゃんははっきり言って命名がヘタクソである。私も別に命名に自信ニキという訳ではないが、まぁ困ったちゃんよりは上手く命名していると思うし、自分の命名で困ったこともあまりないので書いてみる。

以降、サンプルコードにC#を用いるが別にどの言語でも共通する話だと思う。難しいことは書かないのでC#がわからなくてもだいたい読めると思う。

なぜ命名が大事か

簡潔に言うと情報量の違いだと思う。

極端な例だが、次のような変数宣言があるとする。

decimal price = 100;

priceは価格・値段といった意味だが、はっきり言ってpriceという文字だけでこれが何に使われるのか正確にはわからない。

具体的には以下のような情報が欠けている。

単価？小計？合計？
税込み？税抜き？
（キャンペーンなどがある場合）割引適用前？適用後？
単位は日本円？ドル？

こういった情報はできるだけ変数名に明示的に盛り込むべきだと考える。

// 単価なら
decimal unitPrice = 100;

// 小計なら
decimal subTotal = 100;

// 合計なら
decimal total = 100;

// 税込みなら
decimal taxIncludedPrice = 100;

// 税抜きなら
decimal taxExcludedPrice = 100;

// 割引適用前なら
decimal undiscountedPrice = 100;    // または originalPrice

// 割引適用後なら
decimal discountedPrice = 100;

// 単位が縁
decimal price_yen = 100;

// 単位がドル
decimal price_dol = 100;

といった具合に変数名に情報量を持たせることで可読性を上げることができる。

この考え方は一部、アプリケーションハンガリアンといわれる考え方と一致する。

たとえば、

decimal total = price_yen + price_dol;

のようなコードはドルと日本円を加算しており、明らかに間違いだということが見ただけで分る。正しくは

// ドルは円に換算して可算する
decimal total = price_yen + ConvertToYen(price_dol);

としなければならないと判断できる。これが命名が持つ強力なメリットであり、命名にこだわる理由である。

こういった考え方が活きる場面はたくさんある。

// パスワード
string password = "XXXXX";
// パスワードを更新
user.updatePassword(password);

これだと、passwordで更新しているが、うっかりpasswordが平文のままだったら平文がそのまま登録されているかもしれない。

もし変数名をplainPasswordなどとしていれば平文のパスワードということが見ただけで分かるので、登録前にハッシュ化させる必要があると気づけるだろう。

// 平文のパスワード
string plainPassword = "XXXXX";
// ハッシュ
string hashedPassword = plainPassword.Hash();
// ハッシュ化されたパスワードで更新
user.updatePassword(hashedPassword);

また、コーディングミスにより

// 誤って平文で更新するコードになっている
user.updatePassword(plainPassword);

と書いてしまっていたとしても、「平文で更新するっておかしいよね？」と気づくきっかけになるハズだ。

このような「これは税計算必要なの？」「これは平文？」などの情報はよくコードを読めば分かることではある。だがその「よくコードを読む」作業を意識から切り離して、本来考えたいアルゴリズムや可読性などに集中できるのが大事だ。そしてそれは命名の工夫をするだけで改善できることでもある。

汎用性の高い接頭辞や接尾辞もあるので、それらはいつでも使えるようになっておくとベストだ。

xxxFlgという変数名

真偽値などでxxxFlgなどという命名をしているのをたまに見かけるが、これもあまり優しくないと思う。

例えばdeleteFlgという変数名があるとする。これは以下のように様々な解釈が可能である。

削除済みのデータであることを示すフラグ
削除できる状態のデータであることを示すフラグ
削除しなければならないデータを示すフラグ
削除される予定のデータであることを示すフラグ

などだ。deleteとしか書かれていないのだから如何様にも解釈できる。trueで削除済みなのかfalseで削除済みなのかも、変数名からは分からない。個人開発ならともかく、チームで開発するプロジェクトにおいて「そんなつもりで命名した訳じゃない」「普通に考えたらこう」なんていうのは通用しない。何故ならそのコードは自分だけではなく、他の誰かが読んだり修正したりするかもしれないからだ。個人開発だとしても、何日も経って忘れたころに見直すこともあるだろう。だからこそ、直感的に分かりやすい命名をする必要がある。

真偽値の命名にはis, has, can（もしくはis～able）, shouldなどを使うと可読性が上がると言われている。それらはY/N質問として読めるし、意味のはき違えようがないからだ。

// 削除済み
bool isDeleted = true;

// 削除できる
bool canDelete = true;
bool isDeletable = true;

// 削除しなければならない
bool shouldDelete = true;

これだと、isDeletedは「削除済みか？」に対してtrue(削除済み)かfalse(削除済みではない)とハッキリするのである。isDeletedという変数名で「trueだから『削除しなければならない』ってことだな！」「trueだから未削除なんだな！」と解釈する人はまずいないだろう。それは考え方とかじゃなくて英語力の問題だから…。

コメントで補えるのでは

命名をシンプルにしてコメントで補えるのでは、と思うかもしれない。確かにそういう手もあるが、個人的には望ましくないと考える。なぜか。

それはコメントはメンテしないといけないからだ。

// 税抜き価格
decimal price = 100;

というコメントをつけたコードがあったとする。これが税込み価格を反映するという修正が必要になった場合、

// 税抜き価格
decimal price = 110;

と修正するだけでなく、コメントも

// 税込み価格
decimal price = 110;

と直さなければならなくなる。修正の工数がしっかり確保されており、コメントも含めてレビューされるような環境であればまだいいかもしれないが、多くの場合修正レビューはテストが通るかどうかと差分の比較であり、コメントは忘れ去られる。動作は自動テストが保障してくれるかもしれないが、コメントが合っているかどうかは人の目でみないと分からない。

もしコメントのメンテを怠ると、そのコメントは嘘になる。コメントに嘘が書いてあるくらいなら、コメントがない方が100倍ましだ。そうやって嘘のコメントが積み重なって保守不可能な過去の遺産になっていく。コメントで意味を補足するくらいなら、taxExcludedPriceやtaxIncludedPriceなどの具体的な意味を持った命名をした方が良い。

システムハンガリアンは…

前述した「アプリケーションハンガリアン」とは別に「システムハンガリアン」という考え方もあるが、これは現代ではもはや推奨されていないシーンの方が多い。以前は私も使っていたが、最近はまず使わないようになった。

string sName = "あぱしょに";
int nAge = 27;

システムハンガリアンは、string型ならsやstr、int型ならnやintのように、各変数の型を識別できる接頭辞を入れるというものだ。

これも同様にコードを見ただけでエラーが分かるようになるというハックの一つだが、静的型付け言語ではたとえば

string sName = "あぱしょに";
int nAge = 27;
int hoge = nAge * sName; // エラー

などと間違えて書いても

のように教えてくれるので、変数を見ただけで型の不一致がわかるというメリットは少ない。動的型付け言語であれば違うと思うが…。

また、システムハンガリアンは型を変更した際に変数名も修正しなければならない（そうでないとシステムハンガリアンのメリットが正しく発揮されない）。たとえばnUserIdをint型からstring型に変更した場合は、型だけでなく変数名もsUserIdと変更しなければならず、これは大変な手間である。

そういった理由で、システムハンガリアンは現代ではほとんど見られなくなった（少なくとも私の観測範囲では）。これからも私が積極的に使うことはないだろう。昔の案件の修正などで既にコーディングスタイルが指定されていれば従うが。

英語にこだわらなくていい

個人的には無理して英語にこだわって意味不明な変数名になるよりは、別にローマ字でもいいから意味が分かるよう正確に命名してほしいと思っている。

また、英語に自信がなければcodicやDeepLなど便利なサービスもあるので、それらも活用したい。特に前者はネーミングに特化しているだけでなく、camelCaseやsnake_case、PascalCaseなど自由にスタイルをカスタマイズできる。私はこれらのサービスで色んな語を知った。