cocone engineering

こんにちは。クライアントエンジニアのYです。
本日は表題の通りメソッドの命名方法をまとめてみました。比較的初心者向きです。

10問10答式で、英文法的な観点が多めです。早速いってみましょう。

Q1.そもそもどうやってメソッド名をつければいい？
A1.まずは、日本語(一番得意な言語)で「このメソッドは何をしているか」を書いてみる。

例: サーバーから飼い猫の健康状態のデータをダウンロードする

ここまでわかっていれば、メソッド名に翻訳すれば良さそうです。自力で英訳しても良いですが、今回はChatGPTに頼んでみましょう。

「Hey Chat GPT, 『サーバーから飼い猫の健康状態のデータをダウンロードする』 内容のメソッド名を考えて」

と聞いたところ、以下を挙げてくれました。

どれも良さそうです。
ここでわからない単語を調べると、英語の良い勉強になります。
ちなみに、私のような日本語中心脳の人間が最初から英語で考えようとすると

GetData

のような命名をすることになります。汎用的な命名はメソッド名をみても何をしているのかわからないので、できるだけ避けましょう。

Q2.とりあえず命名の鉄則を知りたい
A2.動詞は最初に置く。

みたいな感じですね。動詞が最初にあれば、役割の根幹が最初に目に入って読みやすいです。文法的にも命令系になりますので、メソッドに何かをさせるという目的に合致します。

Q3. Onで始まるメソッドは何でしょうか。動詞で始まっていないので戸惑いました。
A3.「イベントを発生させるメソッドには、通常「On」が接頭辞として付けられる」という慣習があります。

コード例としては以下のような感じです。

public void OnPresentOpened(){
   PresentOpened?.Invoke();
}

少し噛み砕いてみましょう。
この場合の「On」はおそらく次の意味だと思われます。

Happening after and usually because of: (出典：Cambridge dictionary)
（何かの後に、その何かを原因として引き起こされる）

ピンとこないかもしれませんが、慣れないうちはOnで始まるメソッド名が出てきたらOnをAfter、As soon As、Becauseに読み替えると良いかもしれません。
After Present Opened, As soon as Present Opened, Because Present Opened
みたいな感じです。

Q4. The などの「冠詞」は必要か、それとも不要か
A4. あった方が分かりやすいならば、ぜひつける。

メソッド名がその分長くなってしまうことよりも「その方が意味が明確であるか」を重視します。

Q5. 「猫のごはん」「猫のひげ」などの「所有格」はどう表現するのか
A5. アポストロフィエス（’s）は基本的に省略します。

例えば、

を表現したい場合、

となる事が多いです。より具体的に「その猫が所有している餌」を強調したい場面では

など、語順を変更して冠詞や前置詞を使うのが適切なこともありそうです。
強調したい語を前に持たせたい、前後のメソッド名と統一感を持たせたい、といった観点で命名を検討するのも良いです。

Q6. 前置詞も使って良いのか
A6.前置詞は短い文字数で明確なイメージを伝えられる事が多々あるので、その方がわかりやすければ積極的に使う

Q7.メソッド名が長くなってきてしまいました、、
A7.長くても分かりやすい方が良いです。（明らかに不要な単語は削除する）

上記２つを比較すると①を選択したいところ。
あまりに命名が長い場合は、メソッドの中に複数の機能が詰め込まれていないか考え直すのも大事です。

Q8. Hasから始まるメソッドが現在完了形だとおもったらなんか違いました
A8. 所有を表すHasの可能性が高いです

現在完了形は「〜したことがある」「現在まで〜している」といった意味ですよね。私はそう理解しそうになったのですが、全然違いました。たとえば以下のようなメソッドです。

特定のリソースへのアクセス権を持っているかどうかを判定するメソッド

シンプルに「所有する」という意味のHasの使い方をしています。
自分はこのHasの使い方に最初は違和感がありました。今は慣れてきましたが。皆さんはどうでしょうか。

Q9. Camel case とPascal caseの定義を覚えられません
A9. 以下にまとめてみました

C#において、名前を付ける際は「Pascal case」と「Camel case」に分かれます。
Pascal は各単語の最初の文字を大文字にする書き方。

みたいな感じです。

Camel caseは２パターンあります。１つはパスカルケースと同じ。

もう１つは、一番初めの文字を小文字にする書き方です。

ただし、パスカルケースと比較した文脈においては、camel case は②の意味で使うことが多いです。

「メソッド名はパスカルケース、ローカル変数はキャメルケースで統一しましょう」
みたいな声を聞いたことがあるかもしれません。ややこしいですね。

ラクダはヒトコブラクダとフタコブラクダが存在するので２パターンある、パスカルは言葉の響きが固いので大文字のみ、というイメージで私は覚えています。若干こじつけではありますが、言葉を覚える時は他のイメージと結びつけることが助けになります。

Q10. 元のコードの命名が不適切だが、他人の書いたものを修正するのは気が引ける
A10. 周りのエンジニアに相談しましょう

実際のところ、該当箇所のコードを読むたびに、ほぼ全員が「この命名は微妙だな、読むのに一瞬時間がかかった」と思っていたりします。

つい「既存のコードを、命名といえども変更したくない」という気持ちになりがちなのですが「現在のメンバーも、将来的に加わるメンバーも読みやすい命名」の方が、最終的にチームとしての時間×労力が減りそうです。

現在のメンバーには確認を取りさえすればOKです。勇気を持って相談しましょう。
コードレビューに出す時に「この命名を修正したいです(しました)」と先にコメントを入れておくのも良いかもしれません。

以上です。

個人的にはQ5. の所有格を意識することで、メソッドの命名に悩むことが少なくなりました。

少しでもお役に立てば幸いです。