Apexコーディング規約

By | September 11, 2021
0 Comment

全てのApexClassは下記のコーディング規約を満たすことが期待される。

規約 説明
Loop内にSOQLがない ガバナ制限を回避およびパフォーマンス向上の観点から、Loop内のSOQLは推奨されません。
Loop内にSOQLがない ガバナ制限回避およびパフォーマンス向上の観点から、Loop内のSOQLは推奨されません。
Loop内にDMLがない ガバナ制限回避およびパフォーマンス向上の観点から、Loop内のSOQLは推奨されません。
Loop内に非同期処理がないガバナ制限回避およびパフォーマンス向上の観点から、Loop内のSOQLは推奨されません。
例外処理内以外で不必要なdebug文がない パフォーマンス向上およびセキュリティの観点から、例外処理内以外でのdebug文は推奨されません。
※debug文はキャプチャされない場合でも、transactionの時間およびApex CPU timeを消費します。
if文のネストが深すぎない可読性向上およびメンテナンス性向上の観点から、if文が3階層以上ネストすることは推奨されません。
分岐が多すぎない可読性向上およびメンテナンス性向上の観点から、分岐が10を超えることは推奨されません。
クラスの行数が多すぎない可読性向上およびメンテナンス性向上の観点から 、1クラスの行数が300行を超えることは推奨されません。
メソッドの引数が多すぎない可読性向上およびメンテナンス性向上の観点から 、 メソッドの引数が5を超えることは推奨されません。
publicなメソッドが多すぎない信頼性向上およびテスト性向上の観点から、同一クラス内にpublicなメソッドが6つ以上あることは推奨されません。
フィールドが多すぎない可読性向上およびメンテナンス性向上の観点から、同一クラスに多数のフィールドがあることは推奨されません。
クラス名がUpperCamelCaseで記述されている命名規則の観点から、クラス名はUpperCamelCaseで記述することが推奨されます。
メソッド名がLowerCamelCaseで記述されている命名規則の観点から、メソッド名はLowerCamelCaseで記述することが推奨されます。
フィールド名（変数）がLowerCamelCaseで記述されている命名規則の観点から、変数名はLowerCamelCaseで記述することが推奨されます
フィールド名（定数）が大文字で統一されている命名規則の観点から、定数名は全て大文字であることが推奨されます。
プロパティが小文字でLowerCamelCaseで記述されている命名規則の観点から、 プロパティは LowerCamelCaseで記述することが推奨されます。
メソッドの引数がLowerCamelCaseで記述されている命名規則の観点から、メソッドの引数はLowerCamelCaseで記述することが推奨されます。
フィールドの宣言がメソッドよりも先になされている 可読性向上およびメンテナンス性向上の観点から、クラス内でのフィールドの宣言はメソッドより前でなされていることが推奨されます。
鍵括弧（Braces）が省略されていない可読性向上およびメンテナンス性向上の観点から、If文・ForLoop文・IfElse文・WhileLoop文における鍵括弧の省略は推奨されません。
globalアクセス修飾子が不必要に利用されていないバグ回避およびメンテナンス性向上の観点から、globalアクセス修飾子は可能な限り回避することが推奨されます。
※以前は、Batchなどのインターフェースにおいてglobalアクセス修飾子の利用が必須でしたが、現在はpublicアクセス修飾子が利用可能となっています。
デバッグ文にLoggingLevelが必ず記載されている出力ログの簡略化および信頼性向上の観点から、デバッグ文には必ずLogging Levelが記載されていることが推奨されます。
全ての単体テストにAssertが記述されているテストの詳細化および目的明確化の観点から、全ての単体テストには必ずAssertが記載されていることが推奨されます。
全てのAssertにメッセージが含まれているAssertによる検証の意図を明確化するため、全てのAssertはメッセージ付きであることが推奨されます。
不要なseeAllData=trueがない単体テストを個別の実データに依存させないようにするため、レポートに関するロジックを例外として、seeAllData=trueの利用は推奨されません。
ApexTrigger内にLogicが記載されていない。可読性向上およびメンテナンス性向上の観点から、LogicはApexTriggerではなくHandlerClassに記述することが推奨されます。
全てのトリガおよびクラスにコメントが記載されているメンテナンス性向上の観点から、全てのトリガおよびクラスにはコメントが記載されていることが推奨されます。
全てのメソッドにコメントが記載されているメンテナンス性向上の観点から、全てのメソッドにはコメントが記載されていることが推奨されます。
同様の処理を記述したコードが重複して記述されていないDRYの原則により、類似した処理のコードが重複して記述されることは推奨されません。
フローで処理可能な内容がApexで記述されていないメンテナンス性向上の観点から、宣言的に開発可能なビジネスロジックをコーディングにより開発することは推奨されません。
一般的な処理が、utilityクラスまたはhelperクラスとして切り出されているDRYの原則により、汎用的な処理は単一のクラス（のメソッド）に切り出されていることが推奨されます。
インスタンス化が不要なケースでは、staticメソッドが利用されている信頼性向上およびパフォーマンス向上の観点から、インスタンス化が不要な場面ではstaticメソッドを利用することが推奨されます。
定数の宣言が定数クラスに切り出されている冗長化回避およびメンテナンス性向上の観点から、定数宣言はロジックを記述する各クラス内ではなく、定数クラス内で行うことが推奨されます。
テストデータ作成がTestDataFactoryクラスを利用してなされている冗長化回避およびメンテナンス性向上の観点から、複数のApexトリガ・Apexクラスを利用する予定がある場合は、TestDataFactoryクラスの利用が推奨されます。
利用されていない変数が存在しない冗長化回避およびメンテナンス性向上の観点から、利用されていない変数は削除されることが推奨されます。
利用されていないコードが存在しない冗長化回避およびメンテナンス性向上の観点から、利用されていない（＝unreachableな）コードは削除されることが推奨されます。
ハードコーディングがないメンテナンス性向上の観点から、ハードコーディングは推奨されません。

参考

PMD