こんにちは。木村です。
今回は月1で行っているプロダクトもくもく会で作成したApexの命名規則フローチャートをご紹介します。

プロダクトもくもく会とは

先日遠藤が以下の記事で言及したように、co-meetingでは毎週水曜に社内勉強会をしています。今回の記事も第1水曜に2時間で行っている「プロダクトもくもく会」での成果物になります。

「プロダクトもくもく会」では、プロダクト共通で課題となっていることや取り入れたい技術などを一つ取り上げ、一緒に実装したり調べたりする会となっています。元々丸1日で行っていたのですが、あまりよい成果物が出ず、数ヶ月前から2時間で集中してやるようにして、だいぶうまく回るようになりました。

今回の記事は最近の会で作成したApexの命名規則のフローチャートのお話です。

命名規則を取り上げた理由

実のところ現状弊社では明確な命名規則は決めておらず、Javaの一般的な命名規則に倣ってねという曖昧なルールで各自命名してきていました。
しかし、実際のところレビュー時に変数名やメソッド名など命名の指摘がそれなりに発生してしまっています。命名をレビューで指摘するのはお互いあまりうれしくはないので、それを減らしたいというのが我々の課題意識でした。

誰かが命名規則を作ればいいのですが、いつも後回しになってしまっていたので、このプロダクトもくもく会でちょっと作ってみようということになりました。ちょうど以下の命名規則の記事を見つけていて、4人で2時間でアウトプットを出すには型がないと厳しいが、このフローチャートを作ると決めればできそう、ということでco-meeting版の命名規則フローチャートを作りました。

目指すところは「英語が得意じゃなくても機械的に命名できること」だったのですが、結果はどうだったでしょうか…

共通ルール

フローチャートは簡潔に表現しており、以下の共通ルールを前提とします。

基本ルール

• Apex変数/メソッド名ともにLower Camel Case

  • 例）orderStatus, getLastSyncDate

• 基本的に単語は略さない

  • 慣例で略語がある場合は略語でよい（Exceptionのeやループのインデックスのiなど）

  • スコープが狭い場合（5行程度）は略してもよい

• 必要な情報はできるだけ入れつつ、できるだけシンプルに

文法的なルール

ここは何を言っているかというと、フローチャートで「名詞」と書いているところは、このルールに従って、例えば「名詞 + 名詞 + 形容詞 + 動詞の過去分詞 + 名詞 + 前置詞 + 名詞」でもOKとなるということを言っています。

• 名詞は形容詞+名詞を含む

  • 例）newLead, invalidUser

• 形容詞は動詞の現在分詞/過去分詞（-ing/-ed）を含む

  • 例）updatingRecord, createdDate

• 形容詞は名詞の形容詞的用法（名詞+名詞）を含む

  • 例）invoiceStatus

• 形容詞は形容詞+形容詞を含む

  • 例）lastViewedDate

• 名詞は名詞+前置詞+名詞も含む（極力使わない）

  • 例）caseWithComment

• 名詞は後置修飾を含む（極力使わない）

  • 例）recordLockedByAdmin

その他の指針

• 英語としての自然さは重視しない。気持ち悪さはある程度飲み込む。

• カタカナ英語っぽいのを推奨する。

• 困ったらChatGPTやCopilotに聞きルールに近いものを選択する。

Apex変数名の命名フローチャート

今回はApexの変数の命名です。以下のようなフローチャートができあがりました。

(1) 形容詞+Date

// 例
作成日 createdDate 形容詞+Date
募集開始日 recruitmentStartDate 名詞+名詞+Date
請求書発行日 invoiceIssueDate 名詞+名詞+Date
商談成立日 closeDate 形容詞+Date
マスター同期最終開始日 masterSyncLastStartDate 名詞+名詞+形容詞+名詞+Date

(2) 形容詞+Datetime

// 例
作成日時 createdDatetime 形容詞 + Datetime
募集開始日時 recruitmentStartDatetime 名詞 + 名詞 + Datetime
請求書発行日時 invoiceIssueDatetime 名詞 + 名詞 + Datetime
商談成立日時 closeDatetime 形容詞 + Datetime
マスター同期最終開始日時 masterSyncLastStartDatetime 名詞 + 名詞 + 形容詞 + 名詞 + Datetime

(3) has+名詞

何か持っているかどうかを表す変数はhasをつけます。

// 例
エラーがあるか hasError has+名詞
日付項目を持っているか hasDateField has+名詞+名詞

(4) is+名詞

基本肯定形ですが、どうしても否定をtrueにしたい場合はisNot+名詞にします。

// 例
MatchingMap経由で作成したレコードかどうか isRecordCreatedByMatchingMap is+名詞+後置修飾（過去分詞+前置詞+名詞）
MatchingMap経由で作成したレコードかどうか isMatchingMapCreatedRecord is+名詞+形容詞+名詞
日付項目を持っているオブジェクトか isObjectHavingDateField is+名詞+形容詞+名詞+名詞

(5) is+形容詞

canなどの助動詞は使用せずできるだけvisibleなどの形容詞で表現します。

// 例
表示しているか isVisible is+形容詞
inputを表示しているかどうか isInputVisible is+名詞+形容詞
XXXの機能が有効かどうか isXXXEnabled is+名詞+形容詞
参加者への変更通知機能の無効化フラグ isChangeNotificationToParticipantEnabled is+名詞+名詞+前置詞+名詞+形容詞

(6) 名詞の複数形

ループ内の変数はこの単数形を使用してください。

// 例
注文一覧 orders 名詞の複数形
新規注文一覧 newOrders 形容詞+名詞の複数形

(7) 名詞+Items

不可算名詞の場合は意味が変でも機械的にItemsをつけます。ループ内の変数は名詞+Itemになります。

// 例
作業項目一覧 workItems 名詞+Items
新規ユーザ情報一覧 newUserInformationItems 形容詞+名詞+名詞+Items

(8) 名詞+Set

// 例
レコードIDセット recordIdSet 名詞+Set
新しく登録された商品セット recentlyRegisteredProductSet 形容詞+形容詞+名詞+Set

(9) 形容詞+Map

リクエストヘッダーのようにkeyとvalueを持つことが自明な用語の場合は、headerMapのように直接的な変数名にし、そうでない場合は何が入っているかわかりやすいように(10)のようにkey,valueを明示する命名にしました。

// 例
HTTPヘッダーのマップ headerMap 名詞+Map
選択リストのオプションのマップ pickListOptionMap 名詞+名詞+Map

(10) 形容詞+<key>+<value>+Map

// 例
レコードIDがキーでレコードがvalueのマップ idAccountMap <key>+<value>+Map
キーがEventRealtionのIdでvalueがGoogle Calendarから取ってきた招待への返信ステータス relationIdGoogleStatusMap <key>+<value>+Map

(11) 名詞

// 例
支払い方法 paymentMethod 名詞+名詞
保留中の注文 pendingOrder 形容詞+名詞
注文キャンセル理由詳細 orderCancelReasonDetail 名詞+名詞+名詞+名詞

まとめ

「英語が得意じゃなくても機械的に命名できること」を目指したのですが、ちょっと難しいなというのが結局のところの結論ですね…

実はもくもく会の後、記事にしようと書き出してみると曖昧なところがぽろぽろ見つかり、なかなか記事が書き上がりませんでした。本当はメソッド名のフローチャートも作ったんですが…

ということで自社でも実運用に耐えるかはまだ未知なのですが、何かの参考になればということで公開します。

結局、人間が「英語が得意じゃなくても機械的に命名できること」をフローチャートで実現するのはちょっと無理そうなので、ChatGPTでがんばってプロンプトエンジニアリングして、WebアプリかVSCodeエクステンションでも作るといいのかもなと考えています。ちなみに今回のルールでChatGPTに命名をさせようプロンプトを書いてみました。なかなかルール通りに命名してくれないのですが、がんばってプロンプトを調整し続ければ可能性はありそうでした。時間があったらトライしてみたいと思います。