---
description: 'Javaベースアプリケーション構築のガイドライン'
applyTo: '**/*.java'
---

# Java開発

## 全般指針

- 最初に、静的解析ツール（SonarQube、PMD、Checkstyle）をプロジェクトセットアップに統合したいかユーザーに確認する。
  統合する場合は、ツール選択と設定についてのガイダンスを提供する。
- ユーザーが静的解析ツールを辞退するか、それらなしで進めたい場合は、以下で説明するベストプラクティス、バグパターン、コードスメル防止ガイドラインの実装を続ける。
- 技術的負債を蓄積するのではなく、開発中にコードスメルを積極的に対処する。
- 特定された問題をリファクタリングする際は、可読性、保守性、パフォーマンスに焦点を当てる。
- IDE / コードエディターが報告する警告と提案を使用して、開発の早い段階で一般的なパターンを捉える。

## ベストプラクティス

- **Records**: 主にデータを格納することを意図したクラス（例：DTO、イミュータブルなデータ構造）については、**従来のクラスの代わりにJava Recordsを使用すべき**。
- **パターンマッチング**: `instanceof`と`switch`式でパターンマッチングを活用して、条件ロジックと型キャストを簡略化する。
- **型推論**: 可読性を向上させるためにローカル変数宣言では`var`を使用するが、式の右辺から型が明確に分かる場合にのみ使用する。
- **イミュータビリティ**: イミュータブルなオブジェクトを優先する。可能な場合はクラスとフィールドを`final`にする。固定データには`List.of()`/`Map.of()`のコレクションを使用する。イミュータブルなリストを作成するには`Stream.toList()`を使用する。
- **StreamとLambda**: コレクション処理にはStreams APIとラムダ式を使用する。メソッド参照を活用する（例：`stream.map(Foo::toBar)`）。
- **null処理**: `null`を返したり受け入れたりすることを避ける。値が存在しない可能性がある場合は`Optional<T>`を使用し、`equals()`や`requireNonNull()`などの`Objects`ユーティリティメソッドを使用する。

### 命名規則

- GoogleのJavaスタイルガイドに従う：
  - クラスとインターフェース名には`UpperCamelCase`。
  - メソッドと変数名には`lowerCamelCase`。
  - 定数には`UPPER_SNAKE_CASE`。
  - パッケージ名には`lowercase`。
- クラスには名詞（`UserService`）、メソッドには動詞（`getUserById`）を使用する。
- 略語とハンガリアン記法を避ける。

### バグパターン

| ルールID | 説明                                                    | 例 / 注意事項                                                                      |
| ------- | ------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `S2095` | リソースはクローズすべき                                 | ストリーム、ファイル、ソケットなどを扱う際はtry-with-resourcesを使用する。            |
| `S1698` | オブジェクトは`==`ではなく`.equals()`で比較すべき         | StringやボックスドPrimitiveで特に重要。                                             |
| `S1905` | 冗長なキャストは削除すべき                               | 不要または安全でないキャストをクリーンアップする。                                    |
| `S3518` | 条件は常にtrueまたはfalseに評価されるべきではない          | 無限ループまたは決して変更されないif条件に注意。                                     |
| `S108`  | 到達不可能なコードは削除すべき                           | `return`、`throw`などの後のコードはクリーンアップする必要がある。                    |

## コードスメル

| ルールID | 説明                                               | 例 / 注意事項                                                            |
| ------- | -------------------------------------------------- | ----------------------------------------------------------------------- |
| `S107`  | メソッドはパラメーターが多すぎるべきではない            | ヘルパークラスにリファクタリングするか、ビルダーパターンを使用する。        |
| `S121`  | 重複したコードブロックは削除すべき                   | ロジックを共有メソッドに統合する。                                       |
| `S138`  | メソッドは長すぎるべきではない                       | 複雑なロジックをより小さくテスト可能な単位に分割する。                    |
| `S3776` | 認知複雑度は削減すべき                              | ネストしたロジックを簡略化し、メソッドを抽出し、深い`if`ツリーを避ける。     |
| `S1192` | 文字列リテラルは重複すべきではない                   | 定数またはenumで置き換える。                                             |
| `S1854` | 未使用の代入は削除すべき                            | デッドな変数を避ける—削除またはリファクタリングする。                      |
| `S109`  | マジックナンバーは定数で置き換えるべき               | 可読性と保守性を向上させる。                                             |
| `S1188` | catchブロックは空にすべきではない                   | 常に例外を意味のある形でログまたは処理する。                              |

## ビルドと検証

- コードを追加または変更した後、プロジェクトが正常にビルドし続けることを確認する。
- プロジェクトがMavenを使用している場合は、`mvn clean install`を実行する。
- プロジェクトがGradleを使用している場合は、`./gradlew build`（Windowsでは`gradlew.bat build`）を実行する。
- ビルドの一部として全てのテストが合格することを確認する。