# Spring Coding Conventions

## About

**Spring Coding Conventions** is a centralized reference for the **architecture, coding, and design standards** recommended for Spring-based projects. It defines a set of **rules and best practices** that guide developers in writing **consistent, maintainable, and high-quality Spring applications**.

This page is intended to cover **structural rules, coding patterns, annotation usage, forbidden APIs, and package organization**, serving as a single source of truth for both **developers and automated enforcement tools** like ArchUnit.

By following these conventions, teams can ensure:

* **Consistent codebase** across modules and projects
* Clear **layer separation** (Controller, Service, Repository, Domain)
* Proper usage of Spring **stereotype annotations** (`@Controller`, `@Service`, `@Repository`)
* Avoidance of **legacy or unsafe APIs**
* Easier **code review, maintenance, and onboarding** of new developers

This page forms the foundation for both **manual adherence** and **automated enforcement**, allowing Spring projects to maintain **robust architecture and coding discipline** over time.

## Purpose

The purpose of the **Spring Coding Conventions** page is to provide a **clear and authoritative guide** for developers on how to write Spring applications in a **consistent, maintainable, and scalable way**.

Specifically, it aims to:

1. **Define standardized coding practices**
   * Establish rules for naming, package structure, annotations, and class placement.
2. **Enforce architectural discipline**
   * Ensure layered architecture (Controller → Service → Repository → Domain) is consistently followed.
3. **Promote code quality and readability**
   * Reduce complexity, prevent architectural erosion, and make the codebase easier to understand and maintain.
4. **Support automated rule enforcement**
   * Provide a reference for tools like **ArchUnit**, which can programmatically validate compliance with the conventions.
5. **Facilitate team collaboration**
   * Create a shared understanding of standards, making code reviews more effective and onboarding faster for new developers.

In short, this section **bridges the gap between theory and practice**, helping teams write better Spring code while enabling automated checks to maintain long-term architectural integrity.

## Benefits

Following the **Spring Coding Conventions** provides multiple advantages for teams and projects:

1. **Consistency Across the Codebase**
   * Standardizes **naming, package structure, and annotation usage**, making the code predictable and easy to navigate.
2. **Improved Maintainability**
   * Clear rules for **layered architecture** and **dependency management** reduce technical debt and simplify refactoring.
3. **Better Readability and Understanding**
   * Developers can quickly understand the purpose and role of a class, method, or module by following consistent conventions.
4. **Enhanced Collaboration**
   * Teams share a **common standard**, reducing friction in code reviews and enabling faster onboarding of new developers.
5. **Reduced Risk of Architectural Violations**
   * Ensures proper **layer separation**, **annotation usage**, and avoids misuse of forbidden APIs.
   * Helps prevent **tight coupling, cyclic dependencies, and architectural drift**.
6. **Support for Automated Enforcement**
   * Provides a **reference for tools like ArchUnit** to programmatically enforce rules and detect violations early in the development cycle.
7. **Higher Code Quality and Reliability**
   * By following established best practices, applications are **more robust, scalable, and easier to debug**.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.pranaypourkar.co.in/the-programmers-guide/spring/best-practice/spring-coding-conventions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.