73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
---
|
|
description: 'Guidelines for building C# applications'
|
|
applyTo: '**/*.java'
|
|
---
|
|
|
|
# Java and Spring Boot Development
|
|
|
|
## General Instructions
|
|
|
|
- Make only high confidence suggestions when reviewing code changes.
|
|
- Write code with good maintainability practices, including comments on why certain design decisions were made.
|
|
- Handle edge cases and write clear exception handling.
|
|
- For libraries or external dependencies, mention their usage and purpose in comments.
|
|
|
|
## Java Instructions
|
|
|
|
- **Records**: For classes primarily intended to store data (e.g., DTOs, immutable data structures), **Java Records should be used instead of traditional classes**.
|
|
- **Pattern Matching**: Utilize pattern matching for `instanceof` and `switch` expression to simplify conditional logic and type casting.
|
|
- **Type Inference**: Use `var` for local variable declarations to improve readability, but only when the type is explicitly clear from the right-hand side of the expression.
|
|
- **Immutability**: Favor immutable objects. Make classes and fields `final` where possible. Use collections from `List.of()`/`Map.of()` for fixed data. Use `Stream.toList()` to create immutable lists.
|
|
- **Streams and Lambdas**: Use the Streams API and lambda expressions for collection processing. Employ method references (e.g., `stream.map(Foo::toBar)`).
|
|
- **Null Handling**: Avoid returning or accepting `null`. Use `Optional<T>` for possibly-absent values and `Objects` utility methods like `equals()` and `requireNonNull()`.
|
|
|
|
## Naming Conventions
|
|
|
|
- Follow Google's Java style guide:
|
|
- `UpperCamelCase` for class and interface names.
|
|
- `lowerCamelCase` for method and variable names.
|
|
- `UPPER_SNAKE_CASE` for constants.
|
|
- `lowercase` for package names.
|
|
- Use nouns for classes (`UserService`) and verbs for methods (`getUserById`).
|
|
- Avoid abbreviations and Hungarian notation.
|
|
|
|
## Spring Boot Instructions
|
|
|
|
### Dependency Injection
|
|
|
|
- Use constructor injection for all required dependencies.
|
|
- Declare dependency fields as `private final`.
|
|
|
|
### Configuration
|
|
|
|
- Use YAML files (`application.yml`) for externalized configuration.
|
|
- Environment Profiles: Use Spring profiles for different environments (dev, test, prod)
|
|
- Configuration Properties: Use @ConfigurationProperties for type-safe configuration binding
|
|
- Secrets Management: Externalize secrets using environment variables or secret management systems
|
|
|
|
### Code Organization
|
|
|
|
- Package Structure: Organize by feature/domain rather than by layer
|
|
- Separation of Concerns: Keep controllers thin, services focused, and repositories simple
|
|
- Utility Classes: Make utility classes final with private constructors
|
|
|
|
### Service Layer
|
|
|
|
- Place business logic in `@Service`-annotated classes.
|
|
- Services should be stateless and testable.
|
|
- Inject repositories via the constructor.
|
|
- Service method signatures should use domain IDs or DTOs, not expose repository entities directly unless necessary.
|
|
|
|
### Logging
|
|
|
|
- Use SLF4J for all logging (`private static final Logger logger = LoggerFactory.getLogger(MyClass.class);`).
|
|
- Do not use concrete implementations (Logback, Log4j2) or `System.out.println()` directly.
|
|
- Use parameterized logging: `logger.info("User {} logged in", userId);`.
|
|
|
|
## Build and Verification
|
|
|
|
- After adding or modifying code, verify the project continues to build successfully.
|
|
- If the project uses Maven, run `mvn clean install`.
|
|
- If the project uses Gradle, run `./gradlew build` (or `gradlew.bat build` on Windows).
|
|
- Ensure all tests pass as part of the build.
|