はじめに
「関数は動詞で始める」
というのは一般的な命名規則とされていますが、Boolean型の返り値を伴うメソッド名に見事にアンチパターンにハマったのでアウトプット。
※個人ブログから技術的アウトプットはQiitaへ引っ越ししたので、こちらは過去に書いたブログとなります。
一般的に良いとされている命名6選（Boolean型）
1/ is + 形容詞
2/ has or is + 過去分詞
3/ can + 動詞原型
4/ 三人称単数
5/ 三人称単数の動詞 + 名詞
6/ should + 動詞原型
1.. is + 形容詞
- 形容詞の状態であるかを尋ねる
ex/ isEmpty , isNull
2.. has or is + 過去分詞
- 動詞の状態となったか（完了、経験、継続）を尋ねる
ex/ hasSent , isChanged , isChecked
3.. can + 動詞原型
- 動詞の挙動が可能かを尋ねる
ex/ canGet , canUpdate
4.. 三人称単数
- 動詞の状態かを尋ねる
- 後に続く名詞が明確な場合に利用
ex/ exists
5.. 三人称単数の動詞 + 名詞
- 動詞の状態に名詞
ex/ existsError , hasRequiredKeys
6.. should + 動詞原型
- 動詞の挙動を行うべきか尋ねる
ex/ shouldContinue , shouldCollect , shouldRedirect
などが一般的。
アンチパターン3選
- check + Something
- is + be
- 動詞原形 + 名詞 文法的に誤り
1. . check + Something
- アンチ理由：YesかNoかが不明確
ex/ checkPesonalityId , checkError
2. . is + be
- アンチ理由：文法的にアウト
ex/
誤) isFail / isEnable
正) isFailed / isEnabled
3. . 動詞原形 + 名詞 文法的に誤り
- アンチ理由：これも文法的な誤り
ex/
誤) existError
正) existsError
指針
ifの仮定文の条件に入れたとき、「変数名 == true」をつけないと文章として成立しない変数名は避ける
良い例
if (hasPersonalityId){
return db.doc
}
> 訳) もしパーソナリティIDを持ってたら、DBのドキュメントを~~~返す
> 文章的に成立する
悪い例
if (personalityIdFlag){
return db.doc
}
> 訳) もしパーソナリティIDフラグなら,DBのドキュメントを~~~返す
> 文章的に成立しない
if (personalityIdFlag == true){
return db.doc~~~
}
> 訳) もしパーソナリティIDフラグがtrueなら,DBのドキュメントを~~~返す
> 文章的に成立する.故に避けるべき変数
例外（関数名）
- 実務でハマったのが以下
ischecked (channelId:string,personalityId:string){
hoge
}
- 意図していた命名の訳：パーソナリティIDがチャンネルIDと一致していたらtrueを返す。
↑の 2.. is + 過去分詞 を意識したが、これだと何がチェックされたかわからない。
つまり、ルールを意識しすぎた。
結果的に、このファイルが何のパーソナリティidが明確であったためにアンチパターンでもある
checkPersonalityId(channelId:string,personalityId:string){
hoge
}
関数名だけではYesかNoか不明確だが、
ディレクトリ構成上で何がYes/Noか明確にされているなら特別にOKだよね
また、変数名ではなく関数名なので、過去分詞にしなくてOKだよねとなり、edは省いてもOK
とレビュー頂き、無事にapprove頂いた。
まとめ
- 「関数は動詞で始める」が基本のキ
- 一般的に良いとされている命名6選は守ろう、アンチパターンも意識する
- 指針である「ifの仮定文の条件に入れたとき、『変数名 == true』をつけないと文章として成立しない変数名は避ける」
- 例外でアンチパターンがOKの場合もある