1 前提

本規約は下記規約を参照・抜粋し社内向けに整備した内容である。
Google Java Style (非公式和訳)

2 ソースファイルの基本事項

2.1 ファイル名

ソースファイル名はそのファイルに(正確に1つ)入っているトップレベルクラスの大文字小文字を区別した名前に加えて .cls という拡張子が付いていること。
命名にはアッパーキャメルケースを使用すること。

2.2 ファイルエンコーディング：UTF-8

ソースファイルは UTF-8 でエンコードされていること。

2.3 特殊文字

2.3.1 空白

改行以外では、 ASCII 水平スペース文字 (0×20) はソース内でどこに現れても良い唯一の空白文字である。以下のことを意味する。
Stringと文字リテラルでのこれ以外の空白文字はエスケープされること。
タブ文字をインデントの目的で使ってはならない。

2.3.2 特別なエスケープシーケンス

特別なエスケープシーケンスを持つ全ての文字(\b, \t, \n, \f, \r, \”, \’ と \\)については8進数表記(\012)やUnicodeエスケープ(\u000a)でなく、
通常のエスケープシーケンスで表記する。

2.3.3 非ASCII文字

残りの非ASCII文字については実際のUnicode文字（例：∞）を使用する。
処理の都合によってUnicodeエスケープを用いる場合、 String.escapeUnicode() メソッドを使用する。

3 ソースファイル構造

3.1 クラス宣言

3.1.1 1個だけのトップレベルクラスの宣言

各トップレベルクラスは1個のファイルに保存される。

3.1.2 クラスメンバーの順序

クラスメンバーや初期化子の順序の選択はわかりやすさに多大な影響を与える。しかしながら唯一の解法は無い。
クラスが異なれば内容は異なった順序で並べられる。重要な事はそれぞれのクラスはそのメンバーを何らかの合理的な順序で並べ、
クラスのメンテナンスをする人が尋ねられた時に答えられるようなることである。
例えば新しいメソッドはクラスの最後に入れることが慣例であるかのように追加されてはならない。
それは「追加された日の順」という結果になるだけであって、合理的な順序ではない。

3.1.2.1 オーバーロードしているメソッド群を分離してはならない

クラスに複数のコンストラクタや同じ名前を持つメソッドがある場合は、別のコードを（privateなメンバであっても）入れることなく連続して並べる。

4 フォーマット

用語についての注釈：「ブロック様の構造物(block-like construct)」とは、クラス、メソッド、コンストラクタの本体を指す。
すべての配列初期化子は任意に「ブロック様の構造物」とみなされて良い。4.8.3.1節配列初期化子を参照。

4.1 中括弧

4.1.1 使えるところでは中括弧は使う

中括弧は if else for do while 文において本体が空でも1行しかなくても使用する。

4.1.2 空でないブロック：K&Rスタイル

中括弧は空でないブロックや、ブロック様の構造物ではカーニハン・リッチースタイル(Egyptian Brackets )に従う。
・開始中括弧の前に改行を入れない。
・開始中括弧の後に改行を入れる。
・終了中括弧の前に改行を入れる。
・終了中括弧の後に改行を入れる。但し、終了中括弧が文やメソッドの本体を終える時のみである。例えば終了中括弧の後に else や、カンマが続く場合は改行をしない。
例：


public void method1(){
    while(condition()){
        method();
    }
}

@Override
public void method2(){
    if(condition()){
        try{
            something();
        }catch(ProblemException e){
            recover();
        }
    }else if(otherCondition()){
        somethingElse();
    }else{
        lastThing();
    }
}

列挙型でのいくつかの例外は、4.8.1節列挙型にて示される。

4.1.3 空ブロックは簡潔に

空ブロックやブロック様の構造物は(4.1.2節で示したように) K&R スタイルでもよい。
また、開始括弧直後で( {} ) の間に文字や改行無しで閉じてよい。
但し、 if/else あるいは try/catch/finally のような複数ブロックの文の場合を除く。
例：


// これは問題ない
void doNothing(){}

// これも同様に問題ない
void doNothing(){
}

// これは問題がある。複数ブロックの文では簡単な空ブロックをつかってはならない。
try{
    doSomething();
}catch (Exception e){}

4.2 ブロックのインデントは空白4個である

新しいブロックあるいはブロック様の構造物が開始した時インデントは空白4個づつ増える。
ブロックが終了したら、インデントは1個前のレベルに戻る。
インデントレベルはブロックを通じてコードとコメントに適用される。4.1.2節の例を参照のこと。（空でないブロック：K&Rスタイル）
編集注：原文は空白2個であるが当社は空白4個とする

4.3 1行毎に1個の文

各文の末尾は改行でなくてはならない。

4.4 1行の文字数制限 120文字

Apex コードの1行の文字数制限は原則120文字である。文字とは任意のUnicodeコードポイントを意味する。
以下の例外を除き、この制限を超えた行は4.5節行の折り返しで述べるように改行されなくてはならない。
Tip: 画面表示上の大小が違っていても、それぞれのUnicodeコードポイントを１個と数える。
例えば全角文字を使う場合、この規約を厳密に守る箇所では制限に達する前に改行して良い。

例外：
1. 文字数制限に従うのが不可能の場合。（例えば、Javadoc内の長いURL、長いJSNIメソッド1参照）
2. コメント内の、コンソールにコピー＆ペーストされるようなコマンド。

4.5 行の折り返し

用語の注記：ある意味では規約に合致している1行のコードを複数行に分けた場合、この行為を行の折り返しと呼ぶ。
どんな状況にも合う改行方法を正確に示すような統一的で決定的なやり方は存在しない。同じコードを改行する正しい方法は複数存在する。
注記：改行の典型的な理由は1行の文字数制限を超えることを避けることであるが、文字数制限を実際に満たしているコードであっても作者の裁量で改行される場合がある。
Tip: メソッドやローカル変数の抽出をすれば、改行をせずに問題を解決できる場合がある。

4.5.1 どこで改行するか

改行の第一原則は、高い文法のレベルで改行することである。また、代入でない演算子で改行するときは、シンボルの前で改行する。
このことは、以下の「演算子ライクな」シンボルにも適用される。
・ドット演算子( . )
・メソッド参照でのコロン２個( :: )
・型演算子の & 記号( )
・catch節でのパイプ記号 ( catch (FooException | BarException e) )
行が代入演算子で改行されるときは、通常シンボルの後ろで改行される。しかしどちらの方法でも問題はない。
このことは拡張 for (“foreach”) 文の「代入演算子のような」コロンにも適用される。
メソッドやコンストラクタ名に続く開始括弧（ ( ）は直後に続いて書かれる。
カンマ( , )はその前のトークンの直後に続いて書かれる。

4.5.2 連続する行は少なくとも４文字インデントする

改行の際、連続する先頭行に続く各行は少なくとも空白4個分、元からインデントする。
複数の連続した行がある場合、インデントは4以上ならいくつでも良い。
一般的に、2個の連続した行が同じインデントレベルであることは、文法的に相似の要素であることと同じである。
4.6.3節の水平位置揃え：全く不要は、あるトークンを前の行に揃えるためいくつかの空白を入れるという非推奨のやり方を防ぐものである。
例：


if(exam && 
    exam2){
    if(exam3){

    }
}

4.6 空白

4.6.1 垂直の空白

単一の空行は、以下の場合で使われる。
クラスの連続するメンバか初期化子の間。フィールド、コンストラクタ、メソッド、ネストしたクラス、static初期化子、インスタンス初期化子。
例外：2個の連続するフィールド（その間にコードがないもの）間での空行は任意である。そのような空行はフィールドの論理的なグループ分けをするのに必要である。
例外：enum 定数間の改行は 4.8.1.節で議論される
ステートメントの間で、コードを論理的にグループ分けしたいため。
必要な場合、クラスの最初のメンバーあるいは初期化子の前と最終メンバーあるいは初期化子の後。（推奨も禁止もしない）
本文書の別の節で入れるよう求められた場所（3節のソースファイル構造など）
複数の連続した空行を入れて良いが、必須でも推奨でもない。
編集注：不要な改行の入力を禁止

4.6.2 水平の空白

言語かあるいは他のスタイルルールの求めを超え、リテラル、コメント、Javadoc以外で単一のASCII空白は以下の場所のみにおいて使って良い。
・すべての二項あるいは三項演算子の両側。また、以下の様な演算子ライクなシンボルにも適用する。
・連続する型パラメータ間のアンパサンド。
・複数の例外を処理するcatchブロックでのパイプ。 catch (FooException | BarException e)
・拡張for文(“foreach”) でのコロン。 ( : )
以下は除外する。
・Object::toString と書かれるような、メソッド参照でのコロン２個。
・object.toString と書かれるような、ドット演算子。
・, : ; の後ろ。
・行末コメントを開始するスラッシュ２個（ // ）の両側。ここでは複数の空白が許されるが必須ではない。
・型と変数の宣言の間。 List list
・任意で、配列初期化子の両括弧の中。
・任意で、括弧・中括弧の前後。
・new int[] {5, 6} と new int[] { 5, 6 } は両方有効。
注意：このルールは行頭行末の空白について要求や禁止をするものと解釈してはならない。内側の空白のみに適用される。

4.6.3 水平位置揃え：全く不要

用語の注釈：水平位置揃えとは前行のトークン(変数名、型名)の真下に次行のトークンが来るように、入れるスペース数を調整するやり方のことである。
このやり方は許されるが、決して要求されない。すでにこうなっている箇所をそのまま維持することすら必要ない。
これは水平位置揃えをやっている例とやっていない例である。


private int x; // これは良い
private Color color; // これも良い
private int   x;      // 許容される。しかし今後の編集で
private Color color;  // 揃えられなくなるかもしれない。

Tip: カラムの調整は可読性を上げるが将来のメンテナンスで問題になる。一行だけ直したいときを考えてほしい。
この変更は以前のきれいな並びをおかしくするだろう。このようなことが発生しうる。
このことは開発者(多分君)に近くの行を同様に直せと求める。そして修正範囲の拡大を引き起こす。一行の変更が長大な変更となる。
最悪意味のない作業になり、良くても変更履歴を汚染し、レビューが遅くなり、マージの衝突がおこるようになる。

4.7 グループ化の括弧推奨

追加のグループ化の括弧は作者とレビュアーが括弧なしでもコードは誤解される余地がないと認めるか、コードが読みやすくなる時のみ省くことが出来る。
すべての読者がApex演算子の優先度表を覚えていると仮定するのは合理的ではない。

4.8 各構造物

4.8.1 列挙型

列挙定数値後のカンマの後ろの改行は任意である。追加の空行（大抵はたった一つ）も許可される。
ありうる可能性は、以下のとおり。


private enum Answer {
  YES ,

  NO,
  MAYBE
}

定数値にメソッドもドキュメンテーションもない列挙型は必要に応じて配列の初期化と同様に整形してよい。(4.8.3.1 節配列の初期化を参照)
private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }
列挙型はクラスであるのでクラスに対する他のルールが全て適用される。

4.8.2 変数宣言

4.8.2.1 宣言ごとに一個の変数

フィールドでもローカル変数でも変数宣言は一個だけの変数を宣言する。 int a, b; のような宣言は使わない。
例外：複数の変数宣言をすることは、forループのヘッダーであれば実施して良い。

4.8.2.2 必要なときに宣言する

ローカル変数はそれを含むブロックやブロック様の構造物の先頭で慣習的に宣言されてはならない。
代わりに、ローカル変数はそのスコープを最小化するために(合理的な範囲で)最初に使う場所の近くで宣言される。
ローカル変数宣言は通常は初期化がされるか、あるいは宣言されてすぐに初期化される。

4.8.3 配列

4.8.3.1 配列の初期化：ブロック様で良い

配列の初期化はあたかも「ブロック様構造物」のようにやって良い。例えば以下の例はすべて有効である。網羅的なリストでは無い。


new int[] {           new int[] {
  0, 1, 2, 3            0,
}                       1,
                        2,
new int[] {             3,
  0, 1,               }
  2, 3
}                     new int[]
                          {0, 1, 2, 3}

4.8.3.2 Cのような配列宣言は禁止

角括弧は型の一部を構成するが、変数はそうではない。 String[] args は良い。 String args[] はダメ。

4.8.4 スイッチ文

用語についての注釈スイッチブロックの括弧の内側は一個以上の文グループである。
それぞれの文グループは一個以上のスイッチラベル（ case FOO: でも default: であっても）とそれに続く一個以上の文であるか、あるいは最後の文グループの場合は0個以上の文である。

4.8.4.1 インデンテーション

他のブロックと同様に、スイッチブロックは空白4個でインデントされる。
スイッチラベルの後に改行が入り、まさにブロックが開始したかのようにインデントレベルは2上がる。次のスイッチラベルではブロックが終わったかのように以前のインデンテーションレベルに戻る。
例：


switch on input {
    when 1{
    }
    wehn 2{
        prepareOneOrTwo();
    }
    when 3{
        handleOneTwoOrThree();
    }
    when else{
        handleLargeNumber(input);
    }
}

4.8.4.2 when else 節は必要

各スイッチ文はたとえコードがない場合でも when else ステートメントグループが必須である。
例外：enum型でのswitch文は、その型の全てのあり得る値を明示的に含めているならば、when else ステートメントグループを省略して良い。
これによりIDEや静的コード分析ツールが何らかの値が漏れていることについて警告を発することが出来るようになる。

4.8.5 アノテーション

クラス、メソッド、コンストラクタに付けられるアノテーションは、ドキュメンテーションブロックの直後に配置される。そして、各アノテーションは１行に１個設定される。
これらの改行は行折り返し(4.5 節行折り返し )に従わない。それ故、インデンテーションレベルも上がらない。
例：


@Override
@Nullable
public String getNameIfPresent(){
     ... 
}

例外：単一のパラメータ無しのアノテーションの場合はシグネチャー行の先頭に現れて良い。
例：


@Override public int hashCode(){
     ... 
}

フィールドへのアノテーションもドキュメンテーションブロックの直後に現れる。しかしこの場合、複数のアノテーション(パラメータが付きの可能性もある)が同じ行に現れても良い。
例：


@Partial @Mock DataLoader loader;

パラメータやローカル変数や型についてのアノテーションには特にルールはありません。

4.8.6 コメント

この節では実装コメントについて扱う。Javadocについては6節 Javadoc にて個別に扱われる。
すべての改行の前には任意で空白が入り実装コメントが続く。そのようなコメントは行を非空白にします。

4.8.6.1 ブロックコメントスタイル

ブロックコメントは周りのコードと同じレベルにインデントされる。 /* … */ でも //… でも同じである。
複数行 /* … */ コメントについては * の位置を前の行の * と同じに揃えなくてはならない。


/*
 * これは         // これも           /* こんなかたち
 * 良い           // 良い              * であっても良い。 */
 */

コメントはアスタリスクや他の文字で描かれた箱で囲わない。
Tip: 複数行コメントを書く際必要に応じ自動フォーマット機能で行折り返ししたい場合は /* … */ スタイルを使うと良い。
多くのフォーマッタは // … スタイルのコメントの改行を直さない。

4.8.6.2 修正コメント

運用保守においてコードの著者(6.4.1 節著者を参照)以外の人物がコードを修正する場合、当該箇所の始点と終点にコメントを記載する。
始点には修正理由・修正者・日付を記載する。
例：


// 2022/07/14 mod by s.fukushige 課題対応により start
    ・・・
// 2022/07/14 mod by s.fukushige 課題対応により end

// 2022/07/14 add by s.fukushige 課題対応により start
    ・・・
// 2022/07/14 add by s.fukushige 課題対応により end

// 2022/07/14 del by s.fukushige 課題対応により satre
    /**
    ・・・
    */
// 2022/07/14 del by s.fukushige 課題対応によりend

バージョン管理によって変更履歴が辿れる場合は上記記載を必須としない。

4.8.7 修飾子

4.8.8 数値リテラル

long 型の数値リテラルは大文字の L を末尾に使う。小文字は使わない。数値 1 との混乱を避ける。例えば 3000000000l ではなく 3000000000L を使う。

5 命名

5.1 すべての識別子への共通ルール

識別子はASCII文字、数字のみを使う。また後述するいくつかの場合ではアンダースコアも使う。それゆえ、有効な識別子名は正規表現 \w+ にマッチする。
(注:5.2.4節の定数名の場合と、5.2.3節のメソッド名でのUnitのテストメソッド名の場合)

5.2 識別子の種類ごとのルール

5.2.1 パッケージ名

パッケージ名はすべて小文字で連続する単語をそのまま繋げる。アンダースコアは使わない。
例えば、 com.example.deepspace であって、 com.example.deepSpace や com.example.deep_space は使わない。

5.2.2 クラス名

クラス名はアッパーキャメルケース(UpperCamelCase)で命名する。
クラス名は大抵名詞か名詞句である。例えば、 Character や、 ImmutableList である。
インターフェース名も名詞か名詞句である。（例えば List である。）しかし、場合によっては形容詞や形容詞句になる。（例えば、 Readable である。）
アノテーション型に対する特定のルールや確立した規約はない。
テストクラスはテスト対象クラス名で始まり、 Test で終わるよう命名される。例えば HashTest や、 HashIntegrationTest である。

5.2.3 メソッド名

メソッド名は、小文字キャメルケース(lowerCamelCase)で命名される。
メソッド名は大抵動詞か動詞句である。例えば、 sendMessage や stop である。
アンダースコアはApexのメソッド名において、名前の論理的コンポーネント名（lowerCamelCaseで書かれる）を分離するために使ってよい。
典型的なパターンは test_ で、例えば testPop_emptyStack である。テストメソッドを命名する正しい唯一の方法はない。

5.2.4 定数名

定数はコンスタントケース(CONSTANT_CASE)で命名する。すべて大文字で、各単語を１個のアンダースコアで区切る。しかし定数とは正確には何だろうか。
定数とは、その内容が不変であってそのメソッドは検知可能な副作用を持たないような static final なフィールドである。
例えば、プリミティブ型、String、不変な型、不変な型の不変なコレクションである。
もしインスタンスの観測可能な状態が変化できるなら、それは定数ではない。
単に絶対にオブジェクトを変更しないことを意図するだけでは大抵は不十分である。
例：


// 定数である
static final int NUMBER = 5;
static final ImmutableList NAMES = ImmutableList.of("Ed", "Ann");
static final ImmutableMap AGES = ImmutableMap.of("Ed", 35, "Ann", 32);
static final Joiner COMMA_JOINER = Joiner.on(',');  // Joiner は不変であるので。
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

// 定数でない
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set mutableCollection = new HashSet();
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};
これらの名前は大抵名詞か名詞句である。

5.2.5 定数でないフィールド名

定数でないフィールド名（staticであってもなくても）は小文字キャメルケース(lowerCamelCase)で命名される。
これらの名前は大抵名詞か名詞句である。例えば computedValues や index である。

5.2.6 パラメータ名

パラメータ名は小文字キャメルケース(lowerCamelCase)で命名される。
一文字のパラメータ名は public なメソッドでは避けるべきである。

5.2.7 ローカル変数名

ローカル変数名は小文字キャメルケース(lowerCamelCase)で命名される。
final で不変であってもローカル変数は定数とは見なされないので定数として命名されるのは避けるべきである。

5.3 キャメルケースの定義

時として、”IPv6″や、”iOS”のような頭字語や見慣れない形があるように、英語のフレーズをキャメルケースに変換する合理的な方法は複数ある。
正確さを維持するため、以下のような（ほぼ）決定的な手順を定義する。

名前の通常の形から始めて、
言葉を素のASCIIに変換し、アポストロフィを除去する。例えば、”Müller’s algorithm” は “Muellers algorithm”に変換される。
これをスペースや残っている句読点（大抵はハイフン）で分離し、単語に分割する。
推奨：もしもある単語が通常の利用において既に慣習的にキャメルケースの形をとっているならばそれも分解する。
（例：「AdWords」を「ad words」にする。）「iOS」のような単語そのものは真にキャメルケースになっておらず、どんな規約にも当てはまらないのでこの推奨も適用されないないことに注意すること。
（頭字語を含めて）すべてを小文字にする。そして以下の語の最初の文字を大文字にする。
それぞれの単語。この場合大文字キャメルケースとなる。
最初の単語を除いたそれぞれの単語。この場合小文字キャメルケースになる。
最後に、すべての単語を１個の識別子として連結する。
元々の単語の大文字小文字はほとんど全て無視される。
例：

元々の形	正しい変換例	誤った変換例
XML HTTP request	XmlHttpRequest	XMLHTTPRequest
new customer ID	newCustomerId	newCustomerID
inner stopwatch	innerStopwatch	innerStopWatch
supports IPv6 on iOS?	supportsIpv6OnIos	supportsIPv6OnIOS
YouTube importer	YouTubeImporter YoutubeImporter※

※やってよいが推奨されない。
注釈：いくつかの単語は英語として曖昧にハイフン付けされている。例えば、”nonempty” と “non-empty” はどちらも正しい。
それゆえ同様に checkNonempty と checkNonEmpty というメソッド名はどちらも正しい。

6 プログラミングの実践

6.1 キャッチされた例外：無視しない

以下の例を除き、キャッチした例外についてなにも対応しないことが正しいことはめったにない。（典型的な対応はログを取るか、ありえない場合ならば AssertionError として再スローすることである。）
キャッチ節でなにもしないことが本当に適切であるならば、それを正当化する理由をコメントで説明する。


try{
    int i = Integer.parseInt(response);
    return handleNumericResponse(i);
}catch(NumberFormatException ok){
    // 数字ではない。正常であるので続行する。
}
return handleTextResponse(response);

例外：テストにおいて、キャッチされた例外が、 expected と命名されているあるいは始まる名前である場合は、コメントなしで無視してよい。
以下の例はテスト対象のコードが期待した型の例外をスローすることを確認するためのよくあるイディオムであり、コメントは不要である。


try{
    emptyStack.pop();
    fail();
}catch(NoSuchElementException expected){
}

6.2 staticなメンバー：クラスを使って修飾する

staticなメンバーを修飾する必要がある場合はクラス名を使う。そのクラスの変数や式経由で使ってはならない。


Foo aFoo = ...;
Foo.aStaticMethod(); // 良い
aFoo.aStaticMethod(); // 悪い
somethingThatYieldsAFoo().aStaticMethod(); // とても悪い

6.3 三項演算子の使用

三項演算子の使用は禁止しないが1行が文字数制限(120字)を超過する場合はif文を使用する

7 Javadoc(看板コメント)

編集注：Doxygenで使用可能

7.1 フォーマット

7.1.1 一般的なフォーマット

Javadocブロックの基本的なフォーマットはこの例で表される。


/**
 * 複数行のJavadocテキストはここに書かれる。
 * 普通に改行される。
 */
public int method(String p1) { ... }

一行の例はこうである。


/** 特に短いJavadoc */

基本的な形は常に適用される。
一行の形はJavadocブロック全体（コメントマーカを含む）が１行で書ける場合のみ置き換えることができる。
これは@returnタグのようなブロックタグが存在しない場合のみ適用可能であることに注意すること。

7.1.2 段落

一つの空行つまり先頭のアスタリスク(*)のみの行が段落と段落の間に挿入される。もしブロックタググループがあるならばその前にも挿入される。
最初以外のすべての段落には、最初の単語の前に空白無しで改行が入れられる。

7.1.3 ブロックタグ

全ての標準のブロックタグでで、実際に利用されるものは @param, @return, @throws, @deprecatedの順で現れる。これらの４つには記述が必ず存在しなくてはならない。
ブロックタグが１行コメントに収まらない場合、２行目以降は @ の位置からスペース４個以上インデントされる。

7.2 要約の記述

全てのJavadocブロックは簡単な要約の記述から始まる。この記述はとても重要である。なぜならクラスやメソッドの索引のような特別な場所に現れる唯一のテキストだからである。
この記述は小さな断片の形である。つまり名詞句か動詞句であって、完全な文であってはならない。
「このクラス {@code Foo} は…」とか「このメソッドは…を返す。」で始まってはならないし、「結果を保存しなさい。」という命令形であってもならない。
他方においてこの断片はあたかも文であるかのように大文字に変えられたり、句読点が付けられる。
Tip: /** @return 顧客ID */ といった簡単なJavadocを書くことはよくある間違いである。これは間違いで正しくは以下のように直されるべきである。 /** 顧客IDを返す。 */

7.3 Javadocが使われる場所

少なくとも、Javadocは public なクラスとそのクラスの public 、 protected なメンバーに書かれる。但し以下の例外がある。
追加のJavadocコメントがある場合がある。7.3.3節不要なJavadoc にて解説される。

7.3.1 例外：自己叙述的なメソッド

Javadocは getFoo のような簡単で明確なメソッドの場合は必須ではない。つまり、「fooを返す」以外の意味ある情報が本当に無い場合である。
Tip: 重要：典型的な読者が知りたがるような関連情報を省略することを正当化するためにこの例外を引用するのは適切ではない。
例えば、「getCanonicalName」というメソッドにおいて典型的な読者が「canonical name」という語の意味を知らないかもしれない場合、（単に /** canonical name を返す。 */ と書くだけであるという理由で）省略してはならない。

7.3.2 例外：オーバーライドするメソッド

親クラスのメソッドをオーバーライドするメソッドについてはJavadocは必須ではない。

7.3.3 必須ではないJavadoc

他のクラスとメンバーにもJavadocは必要に応じて書かれる。
クラスやメンバの全体の目的を記述するのに実装コメントが使われているならば、そのコメントは代わりにJavadocで書かれる。（ /** ）
必須ではないJavadocは7.1.2, 7.1.3, 7.2 節のフォーマット規則に従うことがもちろん推奨であるが、必ずしも必要ではない。

7.4 必須記載事項

7.4.1 著者

すべてのクラスのJavadocでは著者を記載すること
copyrightは当社著作物を作成する際に記載する
例：


/**
 * example Class
 * @auther s.fukushige 
 * copyright NIHON SYSTEM & DESIGN, INC
 */
public with sharing class BlogTempateController {

}

/**
  * @description メソッド概要
  * @param param1 パラメータ概要
  * @return 戻り値
  */

こんにちは！
先日2022/03/10に開催された「Spring’22 リリース注目の新機能〜開発者向け〜」に参加しました。
今回のウェビナーに参加できなかった方のために内容をざっくりまとめてみます。

講義の資料はこちらからダウンロードできます。

trailhead.salesforce.com

File Detail | Salesforce Trailblazer Community

https://trailhead.salesforce.com/ja/trailblazer-community/files/0694S000002HkvDQAS?tab=overview

Trailhead, the fun way to learn Salesforce

大まかに分けると内容は自動化プロセスと LWCのアップデートの話でした。

・自動化プロセス
○フロー
●自動レイアウトの正式リリース
●画面フローのフッター表示
●フロートリガエクスプローラ
●レコードトリガフロー
○オーケストレータ
・LWC
○Lightning Web セキュリティ
・その他の新機能
○第二世代管理パッケージからのメタデータコンポーネントの削除
○sfdx force:sourceコマンドのアップデート
・まとめ

○フロー

●自動レイアウトの正式リリース

以前からbeta版として利用できた自動レイアウトが正式リリースされました。

有効にすると今まで通り、フローが自動で見やすくレイアウトされます。
また、今まではできなかったループ内のパスをループ外に接続したり、ループ内でフローを終了したりすることができるようになりました。

●フローナビゲーションボタンのカスタム表示ラベル

画面フローのフッターのボタンに表示されているテキストを設定できるようになりました。いままではAuraコンポーネントなどの開発が必要でしたが、標準で簡単に変更できるようになりました。

●フロートリガエクスプローラ

フローをオブジェクトごとに表示できるようになりました。

フローの設定から表示することができます。

この例では取引先レコードが更新されたときに実行されるフローを一覧表示しています。フローは実行タイミングの種類ごとでは実行順に表示されます。ただし、現状各フローは次で紹介する実行順ではなく表示ラベル順になってしまうようです。

●レコードトリガフローの実行順序の指定

レコードトリガフローの実行順序を設定できるようになりました。ただ、各フローの中で設定する必要があり、一括で管理することはできないようです。

設定を確認するにはまず、各フローのプロパティを表示します。

続いて「詳細を表示」リンクをクリックします。

「注文をトリガ」という項目があるのでここに優先度を数値で設定します。この項目を設定すると数値が小さいフローから実行されます。

ちなみに異なるフローで同じ値が設定されたフローはAPI参照名順で実行され、優先度が設定されていないフローは優先度が1000以下に設定されたフローより後に、1001以上に設定されたフローより前に作成日順で実行されるそうです。

○オーケストレータ

今回追加されたオーケストレータは「フローなどを組み合わせて業務フロー全体にまたがる複雑なプロセスの自動化機能」です。コーディングが必須ではなく、単体のフローよりも長いスパンのビジネスロジックを管理することができます。オーケストレータにはユーザ操作を待機する機能もあり、トランザクションをまたがって実行させることができます。

オーケストレータも「新規フロー」から作れます。また、作成済みのオーケストレータもフロー一覧に表示されます。

フローのように要素で構成されますが、フェーズと決定で構成されます。

フェーズ
・処理 (ステップ) のまとまり
・フェーズごとに終了条件を設定
決定
・フェーズ間の分岐ロジック
・ステップの戻り値を使用可能

フェーズの中には複数のステップを設定可能で、ここにフローや承認などの処理が設定されます。
フローは画面フローも自動起動フローも設定可能です。
ステップ
・対話型ステップ (画面フロー)
・バックグラウンドステップ (自動起動フロー)

○Lightning Web セキュリティ(LWS)

Lightning コンポーネント(Aura)を使用している環境では非推奨

LWSはAuraやLWCなどの画面側の開発機能とは異なり、LWCが動くアーキテクチャとのことです。
このような基礎となるものは、例えば、今までのアーキテクチャではLightning Lockerが使用されていました。
なお、LWSとLightning Lockerの違いは、Lightning Lockerでは制限されていたJavaScript標準機能を使用できるようになり、より高速になることだそうです。

○第二世代管理パッケージからのメタデータコンポーネントの削除

第二世代管理パッケージの場合、管理パッケージに含まれるメタデータを削除できるようになりました。
機能を有効化するためにはパートナーコミュニティにケースを起票する必要があるそうです。

○sfdx force:sourceコマンドのアップデート

パッケージを開発している場合はパッケージごとに以下のコマンドを使えるようになりました。

force:source:push force:source:pull force:source:status force:source:tracking:clear force:source:tracking:reset

force:source:legacy:push などの形式でいままでの仕様のコマンドも使えるそうです。
なお、アップデート前に作成したスクラッチ組織は新しいコマンドに対応していないのでlegacyをつける必要があるそうです。

いかがでしたでしょうか？
個人的にはフローに力を入れてきているなと感じました。
作ってみるとフローは結構サクサク作れるので便利になるのはありがたいです。
ただ、フローは1トランザクションに2000要素しか実行できないというガバナ制限があるので複雑にしすぎないよう気を付けたいところです。
また、LWSはLightning Lockerに悩まされる場面も多かったため期待はありますが、Auraを使えないとなるとすぐに導入できる場面は少なさそうです。
こちらは今後のアップデートに期待でしょうか。

以上、最後までご覧頂きありがとうございます。

[参考]
・File [JP]Spring ’22 | Salesforce Trailblazer Community (https://trailhead.salesforce.com/ja/trailblazer-community/files/0694S000002HkvDQAS?tab=overview, 2022/03/14)
・Learn MOAR in Spring ’22 with Flow Enhancements ? – Salesforce Admins (https://admin.salesforce.com/blog/2022/learn-moar-in-spring-22-with-flow-enhancements, 2022/03/11)
・Salesforce フロー (https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow.htm&type=5&release=236, 2022/03/11)
・Go with the Flow: What’s Happening with Workflow Rules and Process Builder? – Salesforce Admins (https://admin.salesforce.com/blog/2021/go-with-the-flow-whats-happening-with-workflow-rules-and-process-builder, 2022/03/11)
・Learn Moar in Spring ’22 with Orchestrator ? – Salesforce Admins (https://admin.salesforce.com/blog/2022/learn-moar-in-spring-22-with-orchestrator, 2022/03/14)
・オーケストレータ (正式リリース) (https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_orchestrator.htm&type=5&release=236, 2022/03/14)
・Orchestrator Basics | Salesforce Trailhead (https://trailhead.salesforce.com/en/content/learn/modules/orchestrator-basics, 2022/03/14)
・Learn MOAR in Spring ’22 with Lightning Web Security | Salesforce Developers Blog (https://developer.salesforce.com/blogs/2022/02/learn-moar-in-spring-22-with-lightning-web-security, 2022/03/14)
・Lightning Web Security Overview – Salesforce Lightning Component Library (https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.security_lwsec_intro, 2022/03/14) 日本語03/14現在、まだ利用できない→https://developer.salesforce.com/docs/component-library/documentation/ja-jp/lwc/lwc.security_lwsec_intro
・Lightning Web セキュリティによるコンポーネントのセキュリティの改善、強化、迅速化 (正式リリース) (https://help.salesforce.com/s/articleView?id=release-notes.rn_lws_ga.htm&type=5&release=236, 2022/03/14)
・Remove Metadata Components from Second-Generation Managed Packages | Salesforce DX Developer Guide | Salesforce Developers (https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_remove_md_components.htm, 2022/03/14)
・cli/README.md at main · forcedotcom/cli (https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md, 2022/03/14)
・source Commands | Salesforce CLI Command Reference | Salesforce Developers (https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_source.htm#cli_reference_force_source_legacy_pull, 2022/03/14)

こんにちは！
今回はWinter '22のリリースノート日本語版が出たということで、いくつか開発周りで気になったものをご紹介。
今回は劇的にできることが広がるようなものは……とはいえこういう細かいところを見落とさないようにするのも大事大事、ということで。

EnumのValueofメソッド

意外と痒い所に手が届くメソッド。入力文字列から列挙型に変更したりなんだり。switch文で分岐させるときの型変換がこれで楽になるのでは。コードは以下のイメージ

public class testEnum {

public enum Winner {AlmondEye, ReyDeOro, KitasanBlack, Maurice} public void testMeth(String str){ Winner currentWinner = Winner.valueOf(str); system.debug(currentWinner); } }

これを実行するとこんな感じ

testEnum te = new testEnum(); te.testMeth('AlmondEye');

ちなみに列挙にない値を渡すとNoSuchElementException

< lightning:inputField/lightning:outputFieldの時間型対応

こちらも使わないようであると便利な痒い所。これで日時型からあーだこーだしなくてよくなる。

lt;aura:component implements="flexipage:availableForAllPageTypes,flexipage:availableForRecordHome,force:hasRecordId,force:lightningQuickAction" access="global" >


    <lightning:recordViewForm recordId="********" objectApiName="Account">
           <lightning:outputField fieldName="DateTimeTest__c" />
    </lightning:recordViewForm>


    <lightning:recordEditForm aura:id="recordViewForm" recordId="********" objectApiName="Account">
        <lightning:inputField  fieldName="DateTimeTest__c" />
    </lightning:recordEditForm>

</aura:component>

イメージは以下の感じ

lightning:accordionSectionのセクションタイトル

lightning:accordionSectionのセクションタイトルが長すぎる場合省略表示されるようになった様子。微妙な差異だけどデザイン上は地味に響きそう。

イメージは以下の感じ。

と、今回はこんな感じで3つほどの紹介でした。

次はまた気になったものがあれば紹介しようと思います。では、オタッシャデー

contact

ご相談・ご質問等ございましたら、お気軽にお問い合わせください。

お問い合わせ

目次