はじめに
Salesforce 関連の命名規則の情報が少ないので個人的にこうすればいいだろうというまとめです。以下のサイトをかなり参考にしています。本記事では大まかな命名方針のみ記載しており、メソッド名は動詞で始めるとか抽象的すぎる命名をしないとかまでは踏み込んでません。リンク先はそこまで踏み込んで書かれてるので、そこまで知りたい方はリンク先を是非参考にしてください(丸投げ)
命名規則まとめ
Apex
Apex 周りは Google Style Java Guide などの Java で一般的なコーディング規約に準拠するのがいいのかなと思います。以下の記述も Apex 固有の部分を除けばその仕様に沿っています。メソッド名や変数名などについては記述を省いているので Google Style Java Guide の方を参照ください。
Apex クラス
- UpperCamelCase で基本的にアンダースコアで単語間を繋げない
- ただし Namespace を使う場合はプレフィックスに Namespace を付与し、クラス名と区別できるようアンダースコアで繋げる
- 単数形にする
- 一般的ではない頭字語はつけない
- 一般的な頭字語例: HTTP, URL など
- 頭字語はすべて大文字ではなく先頭のみ大文字とする
❌悪い例
class foo_class // UpperCamelCase ではない
class fooClass // UpperCamelCase ではない
class NamespaceFooClass // Namespace とクラス名がアンダースコアで繋がれていない
class Foo_Class // アンダースコアで単語が繋がれている
class ABCClass // 一般的ではない頭字語を含む
class HTTPClass // 頭字語がすべて大文字
✅良い例
class FooClass
class HttpClass
class FooNamespace_BarClass
Apex テスト
-
Apex クラスと同じだが、下記の制約が足される
- [テスト対象のApexクラス名]Test の形式にする
❌悪い例
@IsTest
class TestFooClass // サフィックスが Test ではない
✅良い例
@IsTest
class FooClassTest
Apex 型名/アノテーション
- UpperCamelCase にする
❌悪い例
@future // アノテーションが小文字
static void doSomething() {
string foo = ""; // 型名が小文字
integer bar = 0; // 型名が小文字
}
✅良い例
@Future
static void doSomething() {
String foo = "";
Integer bar = 0;
}
Apex 予約キーワード
- すべて小文字にする
❌悪い例
Public Class HogeClass // public, class 予約キーワードに大文字が含まれている
Private Static Final String foo = ''; // 各予約キーワードに大文字が含まれている
✅良い例
public class HogeClass
private static final String foo = '';
Apex トリガ
-
Apex クラスと同じだが、下記の制約が足される
- [オブジェクト名][オペレーション]Trigger もしくは [オブジェクト名]Trigger の形式にする
- 前提条件
- 1オブジェクトに対して同じオペレーション(Insert や Update)のトリガを複数作らない
- もしくはすべてのオペレーションを1つのトリガにまとめる
- 前提条件
- カスタムオブジェクトの場合は API 参照名から__cを省いた形をオブジェクト名にする
- [オブジェクト名][オペレーション]Trigger もしくは [オブジェクト名]Trigger の形式にする
❌悪い例
trigger AccountWhenInserting on Account() {} // サフィックスが Trigger ではない
trigger InsertTrigger on Account() {} // オブジェクト名がない
✅良い例
trigger AccountTrigger on Account() {}
trigger AccountUpdateTrigger on Account() {}
Apex 一括処理, Apex スケジューラ, キュー可能 Apex
-
Apex クラスと同じだが、下記の制約が足される
- Apex 一括処理
- クラス名のサフィックスに Batch を付ける
- Apex スケジューラ
- クラス名のサフィックスに Schedule を付ける
- Apex 一括処理と併用する場合はサフィックスに ScheduleBatch を付ける
- キュー可能 Apex
- クラス名のサフィックスに Queueable を付ける
- Apex 一括処理
❌悪い例
class FooClass implements Database.Batchable<sObject> // クラス名の末尾に Batch がない
class FooClass implements Schedulable // クラス名の末尾に Schedule がない
class FooClass implements Queueable // クラス名の末尾に Queueable がない
✅良い例
class FooClassBatch implements Database.Batchable<sObject>
class FooClassSchedule implements Schedulable
class FooClassScheduleBatch implements Schedulable, Database.Batchable<sObject>
class FooClassQueueable implements Queueable
Apex コントローラ, Apex 拡張コントローラ
-
Apex クラスと同じだが、下記の制約が足される
- Apex コントローラ
- クラス名は [Visualforceページ名]Controller にする
- Apex 拡張コントローラ
- クラス名は [Visualforceページ名]Extension にする
- Apex コントローラ
✅良い例
class FooVisualforcePageController
class FooVisualforcePageExtension
SOQL/SOSL
一般的なSQLのスタイルガイドを適用すると良いです。Kickstarter SQL Style Guide あたりがおすすめです。
❌悪い例
select Id, AccountNumber from Account /* キーワードが大文字ではない */
SELECT id, accountNumber FROM account /* 項目名, オブジェクト名が UpperCamelCase ではない */
✅良い例
SELECT Id, AccountNumber FROM Account
カスタムオブジェクト
オブジェクト名/項目名
- UpperCamelCase にする
- 一般的な頭字語はつけない
- 一般的な頭字語例: HTTP, URL など
- 頭字語はすべて大文字ではなく先頭のみ大文字とする
❌悪い例
custom_object
Custom_Object
CCode
✅良い例
CustomObject
CountryCode
入力規則(ルール名)
- [項目名]_[ルール]という形式にする
❌悪い例
Address_validation
Postal_code_check
✅良い例
Address_less_than_60_characters
PostalCode_must_be_7_digits
数式
- 関数はすべて大文字で記述する
- 2項演算子の前後は1つのスペースを空けるか改行を挟む
- ,(カンマ)の後は1つのスペースを空けるか改行を挟む
❌悪い例
if(Shape__c = "Circle", Radius__c ^ 2 * 3.14, /* 関数IFが小文字 */
IF(Shape__c="Square", Length__c^2, 0)) /* = と ^ の前後にスペースがない */
✅良い例
IF(Shape__c = "Circle", Radius__c ^ 2 * 3.14,
IF(Shape__c = "Square", Length__c ^ 2, 0))
Visualforce
Visualforce のソースコードは実質的に HTML なので Google HTML/CSS Style Guide など既存のスタイルガイドに準拠するのが良いです。
Visualforce ページ名
- UpperCamelCase で基本的にアンダースコアで単語間を繋げない
- ただし Namespace を使う場合はプレフィックスに Namespace を付与し、クラス名と区別できるようアンダースコアで繋げる
- 一般的ではない頭字語はつけない
- 一般的な頭字語例: HTTP, URL など
- 頭字語はすべて大文字ではなく先頭のみ大文字とする
❌悪い例
fooPage // UpperCamelCase ではない
namespace_FooPage // Namespace が UpperCamelCase ではない
✅良い例
FooPage
Namespace_FooPage
Lightning
Visualforce の場合と同じく Google HTML/CSS Style Guide など既存のスタイルガイドに準拠するのが良いです。
Lightning コンポーネント
プロセスビルダー
プロセス名
- [オブジェクト名]ハンドラ の形式にする
- 前提条件
- 1オブジェクトに対して複数のプロセスを作成しない
- 前提条件
✅良い例
取引先ハンドラ
API 参照名
-
カスタムオブジェクト名と同じように UpperCamelCase で記述するのを推奨
- Apex での参照時に表記ブレがなくなるため
おわりに
以上だらだら書きましたがこれらを意識して書くのは大分辛いのでチーム内で VSCode などの開発環境に自動フォーマット機能をつけるのを統一するとかツールで解決していく方向に持っていくほうがいいと思います。個人的には IntelliJ のプラグインである Illuminated Cloud2 を使っていて、基本的に上記規則に則っていてとても便利なのでおすすめです。あとは CI とかで検知できればいいのですが SFDX 対応という壁があったりするのである程度落としどころも考える必要があるかなと思います。