Help us understand the problem. What is going on with this article?

モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう

はじめに

他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。
特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。

そこで今回はモデルやメソッドに名前を付けるときの基本的な原則をまとめてみます。
また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。

想定する言語/フレームワーク

この記事の説明ではRuby/Ruby on Railsを想定しています。
ただし、基本的な考え方は他の言語でも同じように使えるはずです。

モデルの名前は名詞にする

例: 「支払い情報」を表すモデルを作りたい場合

  • × Pay
  • ○ Payment

「支払う = payか。よし。」でモデルを作ってはいけません!
payは動詞で、payの名詞形がpaymentです。
Payモデルではなく、Paymentモデルを作りましょう。

例: 「宗教」を表すモデルを作りたい場合

  • × Religious
  • ○ Religion

「He is religiousって習ったよな。よし。」でモデルを作ってはいけません!
religiousは形容詞で、名詞形はreligionです。
Religiousモデルではなく、Religionモデルを作りましょう。

そもそもなんで名詞にするの?

モデルの名前を名詞にしておかないと、pays = Pay.allのように配列を受け取る変数に不自然な名前を付けてしまうことになります。
order.paysのような関連を使う場合も同様ですね。

二つの単語を繋げてモデルを作る場合は 形容詞 + 名詞 or 名詞 + 名詞にする

例: 「添付ファイル」を表すモデルを作りたい場合

  • × AttachFile
  • ○ AttachedFile

「添付する = attach、ファイル = fileだな。よし。」でモデルを作ってはいけません!
fileは名詞ですが、attachは動詞です。
動詞 + 名詞のモデルを作ると、メソッドのように見える場合があります。

# ん?投稿にファイルを添付してくれるのか??
files = post.attach_files

最初の単語は動詞ではなく、形容詞を使いましょう。
ただし、attachの形容詞はないので、代わりに過去分詞形のattachedを使います。
よって、モデル名はAttachedFileとなります。

形容詞 + 名詞だけでなく、UserGroupなど、名詞 + 名詞のモデル名を付けるのもOKです。

処理を実行するメソッドは 動詞のみ or 動詞 + 名詞にする

例: 「Userのステータスをアクティブにする」メソッドを定義する場合

  • × user.active
  • ○ user.activate

「アクティブはactiveだもんな。それ以外ないし。よし。」でメソッドを定義してはいけません!
activeは形容詞です。つまり「アクティブである」という状態を表します。
「アクティブにする」という動作(変更)を表す場合は、activeの動詞形であるactivateを使う方が適切です。
よって、メソッド名はactivateにしましょう。

例: 「チケットの期限切れを通知する」というメソッドを定義する場合

  • × ticket.notify_expire
  • ○ ticket.notify_expiration

「期限が切れる = expire、通知する = notify、だったよな。よし。」でメソッドを定義してはいけません!
expireもnotifyも動詞です。普通は動詞を重ねて使う用法はありません。
動詞の後ろには目的語、つまり名詞を持ってきましょう。
なのでここではnotify(動詞) + expiration(名詞)で、notify_expirationというメソッドを定義しましょう。

名前を付けるときは可算名詞か不可算名詞かを意識する

  • × informations
  • ○ information

「複数形にするときはsを付ければいいんだよな。よし。」で、なんでもかんでも「s」を付けてはいけません!
英語の名詞には可算名詞(countable noun)と不可算名詞(uncountable noun)があります。
可算名詞であれば、a dog, two dogsのように、二つ以上あれば複数形のsを付けますが、不可算名詞は常に単数形です。
そもそも不可算名詞には数えるという概念がないので、an informationやtwo informationsという表現自体が成り立ちません。

あともうひとつ、ソースコード上でよく使われそうな不可算名詞の例を挙げます。

  • × datas
  • ○ data

dataも不可算名詞です。
厳密には「datumという単語の複数形がdata」なのですが、日常的にはdataは不可算名詞として扱われるようです。

不可算名詞の使用は極力避けて工数を節約する(Railsの場合)

Railsではルーティングの定義やモデルの関連で単数形と複数形を使い分けるルールがあります。
確かにRailsではinformationのような不可算名詞も扱えるようにはなっていますが、開発を進めている途中で変に頭を悩ましたり、思わぬ落とし穴にはまったりする恐れもあります。なので、モデルの名前に不可算名詞を使うことには慎重になった方が良いと思います。

モデル名で不可算名詞を使いそうになった場合は、不可算名詞ではない別の可算名詞で言い換えられないかどうかを検討してみてください。

「〜が必要」はneed somethingよりsomething requiredを使う

(2020年1月15日追記)

  • × gate.need_password
  • ○ gate.password_required

※「パスワードが必要」ならtrueを返すメソッドを定義する場合を想定

「必要 = need、パスワード = passwordだな。よし。」でメソッドを定義してはいけません!
「パスワードが必要」というのは厳密に言うと「パスワードが必要とされている」という「状態」を表します。
「動詞+名詞」にすると、「AをBする」という「動作」を表すことになってしまいます。
状態を表したいときは「名詞+動詞の過去分詞形」で書く方が自然です。

さらに、システム用語においては"required"という単語もよく使われます。
たとえば、入力フォームの「必須項目」は英語で言うと"required field"です。

"need"と"require"は微妙にニュアンスが異なります。

need
「必要とする」を表す一般的な単語。特に「主観的に何かを必要としている状態」の場合が多い。

require
needよりも文語的でフォーマルな表現。主に「客観的に見て必要である」というニュアンスがある。

出典:【英語】need/require(必要とする)の意味の違いと使い分け

上記の情報を総合すると「パスワードが必要」というメソッド(またはテーブルのカラム)を定義する場合は、「名詞+動詞の過去分詞形」で"password_required"と書く方が自然です。

やっていいことと、いけないことの区別はわかった。でも僕は日本人なんだよ!?

はい、確かにこうした品詞の違いを苦労なく使い分けることができるなら、そもそもこんな間違いはしないですよね。
外国語の文法をネイティブレベルで習得するのは非常に難しいです。

ではどうすれば、文法的な間違いをなくす(まずは減らす)ことができるでしょうか?

こまめに辞書を引く

「支払う = payだよな。よし。Payモデルを作成!」ではなく、「本当にこれで合ってる?」と自分に問いかける癖を付けてください。
そして、100%の確信がなければ辞書を引いてください。

面倒ですが、まずはこれを習慣化するしかありません。
僕も確信がないときは辞書を引いています。
それを繰り返しているうちにだんだんと英語力が向上して、辞書を引く回数が減っていくはずです。

「辞書を引く」と書きましたが、紙の辞書に限定しているわけではありません。google検索でもOKです。
weblioのような辞典サイトでも単語の品詞は明記されています。

海外サイトを利用して英語を調べる際のTips

日本語のサイトで確信が得られない場合は、海外のサイトで確認してみるのも有効です。
僕の場合、たとえばこんな感じで英語に関する情報を検索しています。

  • 単語そのものの定義を確認したい場合
    • 単語 + define
    • 例: pay define
  • 名詞形や動詞形を確認したい場合
    • 単語 + verb(動詞) or noun(名詞) or adjective(形容詞)
    • 例: pay noun
  • 複数形を確認したい場合
    • 単語 + plural
    • 例: payment plural
    • rails consoleで"payment".pluralizeと打つのもアリ
  • 可算名詞か不可算名詞かを調べたい場合
    • 単語 + countable uncountable
    • 例: information countable uncountable
  • 反対の意味の単語を調べたい場合
    • 単語 + opposite
    • 例: active opposite
  • 最初に思いついた単語がしっくりこない場合

コードレビューしてもらう

他人に自分のコードを見てもらうことで、品詞の間違いを指摘してもらえる可能性があります。
コードレビューを受けるときは、ある程度英語に詳しい同僚に見てもらうことが望ましいです(ネイティブの外国人プログラマなら完璧)。
しかし、そうでなくてもチームとして「品詞の使い分けに注意する」という観点を持っていれば、それなりに効果はあると思います。
レビューする人は「本当にこれで合ってる?」という疑いの目でコードに登場する英単語をチェックしてください。

まとめ: 正しい品詞が選べることは良いプログラマの条件

英文法的に間違った品詞を使ってもプログラムは動きます。
しかし、このページを読んでいるみなさんは「もっといいコードが書けるようになりたい!」と思っているはずですよね? :wink:

「いいコード」の条件の一つには当然「読みやすいこと」も含まれます。
英文法的におかしなコードは読み手の混乱を招くので「読みやすいコード」とは言えません。
なので、「英文法的に正しい品詞を選べるスキル」は、必然的に「良いプログラマが習得しておくべきスキル」の一つになってきます。

もちろん、ネイティブレベルの100%完璧なスキルを習得するのは困難ですし、僕自身もそこまでの自信はありません。
しかし、そこへ向かおうとする意識を持ってコードを書くようにすれば、何も考えていないプログラマよりもずっとスキルが伸びているはずです。

正しい品詞を選んで、読みやすいコードが書ける「良いプログラマ」になりましょう!

あわせて読みたい

和英辞典・自動翻訳だけじゃダメ!もっといい英語名を見つけるためのTips集 - Qiita
=> 和英辞典や自動翻訳に頼らずに、よりよいクラス名やメソッド名を探す方法を紹介しています。

英語力をアップさせる知見がいっぱい!「Rubyistのための英語勉強会」を開催しました - give IT a try
=> 英語が苦手なRubyプログラマのために開催した英語勉強会の内容をレポートしました。

短い時間で十分伝わるレベルの英文を書くための5つのポイント - give IT a try
=> サポートセンターやプルリクエスト用に書く英文をさくっと書くためのノウハウを紹介しています。

2014.05.29追記: "pay"の名詞用法について

以下のようなちょっと気になるコメントをいただきました。

"pay" は名詞としても使えるような気がします。

確かにその通りです。"pay"には名詞としての用法もあります。

公開前に辞書を確認してpayの名詞用法に気付き、「そういう指摘が入るかもしれないから、もっと自明な別の例にした方が良かったかな~」と思いつつ公開しました。
これだけたくさんの人に読まれると、やっぱりそういう指摘も出てきますよね。

ですが、せっかくなのでこの話題についても掘り下げてみましょう。

名詞用法があるからといって、意味まで同じとは限らない

まず確認してほしいのが、「pay(名詞) = payment か?」という点です。
つまり、品詞としては同じでも、意味まで全く同じとは限らないということです。

で、このケースであれば「pay != payment」のようです。
paymentは「支払い一般」に使えますが、名詞のpayは「給料」を指します(辞書で確認してみてください)。
なので、「注文に対する支払い情報」を表すようなケースであれば、payよりもpaymentの方が適切だと思われます。

動詞の名詞用法を採用したときの可読性はどうか?

次に、もし仮に「pay = payment」だったとして、モデルのpayがメソッドと誤解される可能性はないか?という点も検討する必要があります。
もちろん、payに限らず、英語には名詞としても使える動詞が他にもあります(たとえばwalkとか)。
ただし、辞書を見ると動詞の定義が先に載っていて、かつ、名詞としての用法が動詞ほど一般的ではないのであれば、やはり動詞と同じ形の名詞を採用するのは避けた方がいいと思います。

一方、paymentには動詞としての用法はないので、paymentがメソッドと誤解される可能性は低いです。
なので、もし意味的に「pay = payment」だったとしても、名詞であることが明白なpaymentの方がモデルの名前としてベターだと思います。

そもそもこの記事で一番伝えたかったことは何か?

さて、一般的な話として、このように個別に事例を掘り下げていくと、いろいろとツッコミどころが出てきます。
「いやいや、その単語はこういう使い方もあるし」とか、「ネイティブのプログラマに聞いたら、それはどっちでもいいって言われた」とか、「自分だったらこう書く」とか、「コード上ではあえて英文法を無視するケースもあり得る」とか、etc...

ただ、この記事は個々の例について、正しいとか正しくないとか、例外を認めるべきかそうでないかとか、そういう議論をするために書いたのではありません。

この記事で一番伝えたかったことは「 もしあなたが品詞に無頓着で、頭の中で思い浮かんだ英単語を即正式採用するような人だったら、辞書を引くなどして、品詞を確認する習慣を付けましょう 」ということです。

そうすることで、他の人が誤解しにくい「良いコード」をあなたが書けるようになれば、この記事の目的は達成されたことになります。

自然言語はプログラミング言語以上に複雑かつあいまいで、100%正しい単語を選ぶことはネイティブでないと難しいです(いや、たぶんネイティブの人でも難しいはず)。
ただ、それでも品詞や文法に全く無頓着な人と、それを意識しながらコードを書く人とでは、コードの読みやすさに大きな違いが出てくるはずです。
なので、僕としては100%正しい英語でなくても、プログラマは後者のような姿勢であるべきだと考えています。

jnchito
SIer、社内SEを経て、ソニックガーデンに合流したプログラマ。 「プロを目指す人のためのRuby入門」の著者。 http://gihyo.jp/book/2017/978-4-7741-9397-7 および「Everyday Rails - RSpecによるRailsテスト入門」の翻訳者。 https://leanpub.com/everydayrailsrspec-jp
https://blog.jnito.com/
sonicgarden
「お客様に無駄遣いをさせない受託開発」と「習慣を変えるソフトウェアのサービス」に取り組んでいるソフトウェア企業
http://www.sonicgarden.jp
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした