Coding standards are the unsung heroes of software development, quietly shaping the backbone of every successful project. Like the grammar rules of a language, they provide a common set of guidelines that developers adhere to when writing code. From indentation styles to variable naming conventions, coding standards ensure consistency, readability, and maintainability across a codebase. In this blog post, we’ll delve into the importance of coding standards, explore how they enhance collaboration and efficiency within development teams, and discuss best practices for implementing and enforcing them effectively. So, grab your favorite beverage and let’s embark on a journey to unravel the significance of coding standards in the world of software engineering.

ZERO Tolerance means for any code to be accepted in a Pull Request, it must meet the following requirements:

  • 0 Sonarlint issues found
  • 0 JavaDoc errors/warnings
  • Protobuf fully documented
  • JaCoCo reporting 90+% code coverage.
  • Spotless code formatter.

Enforcing strict coding standards is the cornerstone of maintaining high-quality software. Among the myriad of practices, adopting a “zero tolerance” policy in pull requests ensures that only code meeting a predefined set of criteria is accepted into the codebase. This approach not only elevates the overall quality of the software but also fosters a culture of excellence within development teams.

At the heart of this stringent policy lies the requirement of zero SonarLint issues. SonarLint, a static code analysis tool, meticulously scans code for bugs, vulnerabilities, and code smells. By mandating the absence of SonarLint issues, teams uphold a commitment to code cleanliness, which in turn enhances the reliability and security of the software.

In addition to SonarLint checks, adherence to JavaDoc standards is paramount. JavaDoc serves as invaluable documentation for developers, providing insights into the purpose and functionality of code elements. By ensuring zero JavaDoc errors or warnings, teams prioritize clarity and comprehensibility, facilitating smoother collaboration and knowledge transfer among team members.

Furthermore, comprehensive documentation of Protobuf (Protocol Buffers) is essential. Protobuf offers a concise and efficient mechanism for serializing structured data, but its effectiveness hinges on clear documentation. By mandating fully documented Protobuf definitions, teams promote transparency and ease of integration, empowering developers to leverage Protobuf effectively across the codebase.

Aiming for a JaCoCo code coverage of 90% or higher adds another layer of assurance to the quality of the software. JaCoCo, a Java code coverage library, provides insights into the extent to which code is exercised by tests. By setting a high bar for code coverage, teams prioritize thorough testing, mitigating the risk of undiscovered defects and enhancing the robustness of the software.

Finally, integrating a Spotless code formatter into the development workflow ensures consistent code formatting throughout the codebase. Spotless automatically enforces predefined code formatting rules, eliminating the need for manual formatting and reducing the likelihood of stylistic inconsistencies. This adherence to uniform code styling not only enhances readability but also streamlines code reviews and maintenance tasks.

Springboot Layout

In a Spring Boot project, the package layout typically starts at the application level, often referred to as the root package or base package. This package serves as the entry point for the application and contains the main class annotated with @SpringBootApplication. From this root package, sub-packages are organized based on different components and functionalities of the application.

Here’s a breakdown of the package layout:

  1. Application Level (Root Package):
  • com.example.springboot
  1. Sub-packages:
  • config: Contains configuration classes for Spring beans, security configurations, database configurations, etc.
  • controller: Houses Spring MVC controllers responsible for handling HTTP requests and responses.
  • dto: Contains Data Transfer Objects (DTOs) used for transferring data between layers or components.
  • handlers: Contains exception handlers for handling application-specific exceptions.
  • models: Houses domain model classes representing entities within the application.
  • repository: Houses repository interfaces or classes responsible for database interaction (e.g., Spring Data JPA repositories).
  • security: Contains classes related to security configurations, authentication, authorization, etc.
  • service: Contains service interfaces defining business logic contracts.
  • service.impl: Contains implementations of service interfaces.
  • utils: Holds utility classes and helper methods used across the application.

Here’s how the directory layout might look based on the package structure outlined above:

src
└── main
    ├── java
    │   └── com
    │       └── example
    │           └── springboot
    │               ├── Application.java
    │               ├── config
    │               │   └── AppConfig.java
    │               ├── controller
    │               │   └── UserController.java
    │               ├── dto
    │               │   └── UserDTO.java
    │               ├── handlers
    │               │   └── GlobalExceptionHandler.java
    │               ├── models
    │               │   └── User.java
    │               ├── repository
    │               │   └── UserRepository.java
    │               ├── security
    │               │   └── SecurityConfig.java
    │               ├── service
    │               │   └── UserService.java
    │               │   └── impl
    │               │       └── UserServiceImpl.java
    │               └── utils
    │                   └── StringUtil.java
    └── resources
        ├── application.properties
        └── ...

This directory layout provides a clear and organized structure for different components of the Spring Boot application, making it easier for developers to navigate, understand, and maintain the codebase.

By Jeffery Miller

I am known for being able to quickly decipher difficult problems to assist development teams in producing a solution. I have been called upon to be the Team Lead for multiple large-scale projects. I have a keen interest in learning new technologies, always ready for a new challenge.