はじめに

ふじむーです。
実務入って3ヶ月が経ちました。

実務入って結構使うようになった・気にするようになったあれこれをメモしていきます。
今回は変数名やメソッド名のお作法に関することです。

こういうふうに命名するとよき！みたいな命名規則がいくつかありますが、よく使うイメージのものを記載していきます！

もし何か参考になることがあれば幸いです。

変数名やメソッド名にはお作法がある

ポートフォリオ作っている時は、メソッド名や、変数名って自分がわかればオッケーくらいにしか考えてませんでした。
しかし、実務を通じて業界的な命名規則ががあることを知りました。

そもそも、なぜ命名規則に則るのか

改めて調べてみると、こちらが一番しっくり来ました。

この際に命名規則がなく、バラバラになっていると可読性が悪くなることで改修コストが増えたり、バグの原因になる可能性も出てきます。
命名規則「キャメルケース」「スネークケース」「ケバブケース」についてまとめてみましたより

もう少し自分なりの解釈を加えると、

プロジェクトによって変わると思いますが、一つのアプリケーションに何百、何千ものファイルがあって、そこにびっしりコードが書いてあります。
その中から必要なファイルを探し出して、処理を読み、改修や修正作業を行います。

その時コードが読みにくかったら、、、かなりめんどくさそうですよね、、

なので、命名規則に則ることで、処理を想像しやすくなり
読みやすくなる＆間違えにくくなるんだと解釈しています。

よく使っている命名規則

命名規則はいくつかあります。
今回は個人的によく使うイメージのものだけ記載していきます！

スネークケース・キャメルケースを統一すること
単数系・複数形を使い分けること
名前が冗長にならないようにすること
メソッド名の命名規則があること

スネークケース・キャメルケースを統一すること

アンダースコア使うか、区切りが大文字になるかのやつですね。

冒頭にもお伝えしたように、基本的に統一することで、コードの可読性を上げて修正しやすくするためのものと思ってます。

既存のコードに合わせて統一します。

単数系・複数形を使い分けること

その変数に、データが一個だけならば単数系、複数入るなら複数形で書き分けます。
これは、結構驚きでした。

例えば、ユーザーデータを変数に代入するとして、

//詳細用にユーザーのデータ1件だけ取得して、代入する
const user = User.getData()

//一覧用に複数取得して、代入する
const users = User.getList()

上記により、なんのデータが入っているか予想しやすくなります。
複数形なら配列に入っているだろうなあ、あ、やっぱりここでfor回していじくってるなあとかとか。
（ちょっといい例が思いつかなかった）

ちなみにメソッド名も同様な感じで、単体取得ならgetData、複数ならgetListなどと命名されます。
(後述)

メソッド名の命名規則

メソッド名にも命名規則があります。
いろいろありますが、個人的に頻繁に使ったなあと思うものをあげます。

1, 真偽値が返ってくるメソッドは先頭にisをつける
if分の条件とかで使われるイメージです。
例）

//  チェックボックスにチェックされているかどうか
const isChecked

// トーストを表示させるか
const isToast

// お腹が痛いか
const isStomachache

2, コールバックメソッドで何かが起こったタイミングで実行されるものは先頭にonをつける
クリックしたら〜とか入力したら〜とかですね、

例）

//  グリッドの詳細取得
const onDetail = () => {}

// 送信する
const onSubmit = () => {}

// 保存する
const onSave = () => {}

3, CRUDはだいたいget, save, delete, update

こちらも書き方はいろいろありますが、
上記のように書くことが多いです。


async getList(): Promise<> {
}

async getData(): Promise<> {
}

async save(): Promise<> {
}

async update(): Promise<> {
}

async delete(): Promise<> {
}

4, 名前が冗長にならないようにすること
例えばユーザー一覧を取得するメソッドがクラス内で一個だけだとして、
他と被らないのならば、getUserListと書かないようにすると言った感じですね。

//良い例
async getList(): Promise<> {
}

//悪い例 一覧取得は一個だけなので、Userを入れなくてOK
async getUserList(): Promise<> {
}

ちなみに、ライブラリのドキュメントを読んでいてもこのようなルールで記載されており、
このメソッド実行すると複数データが返ってくるんだろうなあとか予想ができたりします。

余談

変数名にdataを使う時、これは複数入るからdatas！と思っていましたが
よくよく調べてみるとdataって英語的には複数形を指しているらしいです。

「data」はラテン語に由来して、「data」は複数形で、「datum」は単数形なので、「data」は厳密にいうと複数形の単語です。しかし、多くのネイティブの感覚では、「data」は質量名詞なので、「data」を単数形の単語として扱います。
「data」は複数形か単数形、どちらでしょうかより

英語的には複数形だけど、お作法的にはsつけた方がわかりやすいのかなあと疑問に思い、
CTOに聞いてみました。

結論：伝わればどちらでも良いと思っている

あくまで、コードの可読性をあげて読みやすくすることが目的だから
相手に伝わるのならdatasとかいても全然問題はないと思うとのことでした。
（業界的にdatasと書くこと結構あるんだとか）

命名規則はいわゆる手段ですね。

最後に

文章を書くときに、メンタルモデルに則って書くと良いと言いますが、
コードを書くときもこれと一緒なのかなと思っています。

メンタルモデルとは...
「これは、こういうモノだろう」とか「このヒトは、こういうヒトだろう」と心のなかで思うことです。
メンタルモデルを考慮した「理解しやすい文章」の書き方についてまとめてみたより

「こういうデータが返ってくるだろう」「これは真偽値を判断しているだろう」といったように
命名規則に則れば、「予測」しやすくなると思います。

そんなイケてるコードがかけるよう、日々精進してまいります。

参考