制御文

1. [必須] switch ブロック内では、各ケースはブレーク/リターンなど、またはプログラム がどのケースで実行を継続するかを示すコメントによって終了する必要があります。switch ブロック内では、両方ともデフォルトです。コードが含まれていない場合でも、ステートメントを含める必要があり、最後に を配置する必要があります。

2. [必須] コードが 1 行しかない場合でも、if / else / for / while / do ステートメントでは中括弧を使用する必要があります。使用しないでください。 using 次の形式: if (条件) ステートメント;

3. [推奨事項] else はできるだけ使用しないことをお勧めします。 - else メソッドは次のように書き換えることができます:

if(condition){
...
return obj;
}

// 次に、else ビジネス ロジック コードを記述します。

説明:if() を使用する必要がある場合... else if()...else... メソッド Express ロジック、[必須] 3 階層を超えないでください。 3 階層を超える場合は、状態設計パターンを使用してください。

良い例:

3 レベルを超えるロジックを持つ If-else コードは、ガード ステートメントまたは状態パターンを使用して実装できます。

4. [推奨事項] 複雑な

ロジックを避けるため、一般的なメソッド (getXxx/isXxx など) に加えて、条件判定で他の複雑なステートメントを実行しないでください。判定結果は、読みやすさを向上させるために意味のあるブール変数名に割り当てられます。

説明:

多くの if ステートメントのロジックは非常に複雑です。読者は条件式の最終結果を分析して、

条件がどのようなものになるかを理解する必要があります。では、リーダーが論理式を誤って解析した場合、どのようなステートメントが発生するでしょうか?

正の例:

//伪代码如下
boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}

反例:

if ((file.open(fileName, "w") != null) && (...) || (...)) {
...
}

5. [推奨事項] ループ本体内のステートメントは次のようにする必要があります。パフォーマンスを考慮して、オブジェクト、変数の定義、

データベース接続の取得、不要な try-catch 操作の実行など、次の操作をループの外に移動して処理してみてください (この try-catch はループの外に移動できますか)。

#6. [推奨] インターフェイス入力パラメーターの保護 このシナリオは、バッチ操作に使用されるインターフェイスに一般的です。

#7. [参考] メソッドでパラメーターの検証が必要なシナリオ:

1) 呼び出される頻度が低いメソッド。 2) 多くの実行時間を必要とするメソッドの場合、パラメーターの検証時間はほとんど無視できますが、

中間の実行がロールバックするか、パラメーター エラーによりエラーが発生した場合、ゲインは時間よりも大きくなります。損失。

#3) 非常に高い安定性と可用性を必要とするメソッド。

4) RPC / API / HTTP インターフェイスなど、外部に提供されるオープン インターフェイス。

5) 機密性の高いアクセス許可の入り口。

###8. 【参考】メソッド内でパラメータの検証が不要なシナリオ: ###

1) 周期的に呼び出される可能性が非常に高いメソッドのパラメータを検証することはお勧めできません。ただし、外部パラメータ チェックについてはメソッドの説明に記載する必要があります。

2) 基礎となるメソッドは頻繁に呼び出され、通常は検証されません。結局のところ、これは純水の濾過の最終段階のようなもので、パラメーターのエラーが最下層に到達するまでは問題が明らかになる可能性は低いです。一般に、DAO レイヤーとサービス レイヤーは同じアプリケーション内にあり、同じ サーバーにデプロイされるため、DAO パラメーターの検証は省略できます。

3) private として宣言されたメソッドは、そのメソッド自体のコードによってのみ呼び出されます。メソッドを呼び出すコードによって渡されたパラメータがチェックされているか、または確実にチェックされていないと判断できる場合は、問題があるため、現時点ではパラメータの検証を実行する必要はありません。