Skip to main content

Java Linting and Static Analysis

Automated code quality checks catch bugs, enforce standards, and improve maintainability before code reaches production. Java provides a rich ecosystem of static analysis tools that integrate seamlessly into builds and IDEs. These tools should be configured in your build system and run automatically in CI/CD pipelines to enforce quality gates.

Overview​

Linting and static analysis complement the Java compiler's type checking by enforcing code style, detecting bugs that compile successfully, and identifying code smells. While the compiler ensures type safety, linting tools ensure code quality, consistency, and adherence to best practices.

Why multiple tools: Each tool serves a distinct purpose. Spotless handles formatting, Checkstyle enforces coding standards, SpotBugs finds bugs through bytecode analysis, PMD detects anti-patterns in source code, and SonarQube provides centralized quality tracking. Using them together creates a comprehensive quality safety net.

Integration points: These tools integrate at multiple levels - IDE warnings during development, pre-commit hooks before commits, and CI/CD pipelines before merging. This multi-layered approach catches issues early while maintaining developer velocity. See our Pipeline Configuration for CI/CD integration patterns.

Code Formatting with Spotless​

Code formatting should be automated and enforced in CI/CD pipelines, never manually reviewed. Spotless is a code formatter that wraps existing formatters (Google Java Format, Eclipse formatter) and integrates with Gradle. It can both check formatting (fail the build if code is incorrectly formatted) and apply formatting automatically.

Why Automated Formatting Matters​

Manual code reviews should focus on logic, not style. Automated formatting eliminates bikeshedding about tabs vs spaces, brace placement, or line length. It ensures every team member sees consistently formatted code regardless of their IDE settings. Most importantly, it prevents "formatting noise" in diffs - changes where the only difference is whitespace, which obscures actual logic changes in code reviews.

Spotless enforces a single, team-wide style automatically. The ./gradlew spotlessApply command reformats all code to match the configured style. Run this before committing to ensure consistent formatting across the team. The CI pipeline should run ./gradlew spotlessCheck to verify all code is properly formatted - builds fail if code is incorrectly formatted, forcing developers to fix formatting before merging.

Configuration​

// build.gradle
plugins {
    id 'com.diffplug.spotless' version '6.23.3'
}

spotless {
    java {
        target 'src/**/*.java'
        // Google Java Format provides consistent, non-configurable formatting
        // Version pinning ensures team uses same formatter version
        googleJavaFormat('1.17.0')

        // Additional cleanup operations
        removeUnusedImports()          // Prevents import clutter
        trimTrailingWhitespace()        // Removes trailing spaces
        endWithNewline()                // Ensures files end with newline

        // Enforce import order: java/javax, then third-party (org, com), then blank
        // Consistent ordering improves readability and reduces merge conflicts
        importOrder('java', 'javax', 'org', 'com', '')
    }
}

// Pre-commit hook integration (optional but recommended)
// Configure Git hooks to run spotlessApply before commits
// See our Git workflow guide for hook setup

Spotless commands:

  • ./gradlew spotlessCheck - Verify formatting without changing files (use in CI)
  • ./gradlew spotlessApply - Reformat all files to match configuration (use before commit)
  • ./gradlew :module:spotlessApply - Format specific module in multi-module projects

IDE Integration​

Most IDEs can import Spotless configuration or use the same formatter (Google Java Format plugins exist for IntelliJ and VS Code). However, relying on CI enforcement ensures everyone adheres to the standard regardless of their IDE setup. See our IDE Setup guide for formatter installation.

Configuring your IDE to use the same formatter as Spotless provides immediate visual feedback during development, but the CI check is the ultimate enforcement mechanism - code cannot merge without passing spotlessCheck.

Static Analysis with Checkstyle​

Checkstyle enforces coding standards beyond formatting - naming conventions, complexity limits, proper Javadoc, and more. Unlike Spotless which auto-fixes violations, Checkstyle reports violations that require manual fixes. This catches issues like overly complex methods, missing Javadoc on public APIs, and naming convention violations.

Checkstyle vs Spotless​

Spotless handles mechanical formatting (whitespace, braces, import order). Checkstyle enforces higher-level standards that can't be auto-fixed - method length, parameter counts, cyclomatic complexity, naming patterns. Use both: Spotless for formatting, Checkstyle for standards enforcement.

Checkstyle analyzes source code and checks it against a configurable set of rules. These rules cover naming conventions, code structure, documentation requirements, and complexity metrics. While Spotless makes code look consistent, Checkstyle makes code follow best practices.

Configuration​

// build.gradle
plugins {
    id 'checkstyle'
}

checkstyle {
    toolVersion = '10.12.4'
    configFile = file("${project.rootDir}/config/checkstyle/checkstyle.xml")
    maxWarnings = 0  // Treat all violations as errors
    ignoreFailures = false  // Fail build on violations
}

// Run Checkstyle automatically with build
tasks.withType(Checkstyle) {
    reports {
        xml.required = true   // For CI reporting
        html.required = true  // For human review
    }
}

checkstyleMain {
    source = 'src/main/java'
}

checkstyleTest {
    source = 'src/test/java'
}

Sample Checkstyle Configuration​

<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
    "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
    "https://checkstyle.org/dtds/configuration_1_3.dtd">

<module name="Checker">
    <!-- Ensure files end with newline -->
    <module name="NewlineAtEndOfFile"/>

    <!-- File length limit (prevent god classes) -->
    <module name="FileLength">
        <property name="max" value="500"/>
    </module>

    <module name="TreeWalker">
        <!-- Naming conventions -->
        <module name="ConstantName"/>  <!-- UPPER_SNAKE_CASE for constants -->
        <module name="LocalFinalVariableName"/>
        <module name="LocalVariableName"/>
        <module name="MemberName"/>  <!-- camelCase for fields -->
        <module name="MethodName"/>  <!-- camelCase for methods -->
        <module name="PackageName"/>  <!-- lowercase for packages -->
        <module name="ParameterName"/>
        <module name="StaticVariableName"/>
        <module name="TypeName"/>  <!-- PascalCase for classes -->

        <!-- Import rules -->
        <module name="AvoidStarImport"/>  <!-- No wildcard imports -->
        <module name="IllegalImport"/>
        <module name="RedundantImport"/>
        <module name="UnusedImports"/>

        <!-- Complexity limits -->
        <module name="CyclomaticComplexity">
            <property name="max" value="10"/>  <!-- Max branches per method -->
        </module>
        <module name="MethodLength">
            <property name="max" value="50"/>  <!-- Max lines per method -->
        </module>
        <module name="ParameterNumber">
            <property name="max" value="5"/>  <!-- Max parameters per method -->
        </module>

        <!-- Code quality -->
        <module name="EmptyBlock"/>  <!-- No empty catch/try/finally blocks -->
        <module name="NeedBraces"/>  <!-- Require braces for if/for/while -->
        <module name="MissingSwitchDefault"/>  <!-- Switch must have default -->
        <module name="SimplifyBooleanExpression"/>
        <module name="SimplifyBooleanReturn"/>

        <!-- Documentation -->
        <module name="JavadocMethod">
            <property name="scope" value="public"/>  <!-- Public methods need Javadoc -->
        </module>
        <module name="JavadocType">
            <property name="scope" value="public"/>  <!-- Public classes need Javadoc -->
        </module>
    </module>
</module>

Common Violations and Fixes​

ViolationWhy It MattersFix
High cyclomatic complexityHard to understand/testExtract methods, simplify conditionals
Missing Javadoc on public APIPoor documentationAdd descriptive Javadoc comments
Magic numbersUnclear meaningExtract to named constants
Overly long methodsHard to maintainBreak into smaller, focused methods
Too many parametersDifficult to use correctlyUse parameter objects or builder pattern

When Checkstyle reports a violation, understand the underlying issue before fixing. High cyclomatic complexity isn't just about lowering a number - it indicates code that's difficult to test and understand. Refactoring to reduce complexity improves code quality, not just the metric. See our Refactoring Guide for strategies.

Bug Detection with SpotBugs​

SpotBugs (successor to FindBugs) performs bytecode analysis to detect potential bugs - null pointer dereferences, resource leaks, concurrency issues, and security vulnerabilities. Unlike Checkstyle which analyzes source code for style, SpotBugs analyzes compiled bytecode for semantic bugs.

Key Difference from Checkstyle​

Checkstyle catches style violations; SpotBugs catches actual bugs. A null pointer dereference that compiles fine will be caught by SpotBugs, not Checkstyle. SpotBugs is particularly effective at finding:

  • Resource leaks (unclosed streams, database connections)
  • Thread safety issues (race conditions, improper synchronization)
  • Security vulnerabilities (SQL injection, insecure random number generation)
  • Correctness issues (incorrect equals/hashCode, impossible casts)

Because SpotBugs analyzes bytecode, it can detect issues that are invisible in source code. It understands data flow and can track how values propagate through methods, catching bugs that require understanding execution paths.

Configuration​

// build.gradle
plugins {
    id 'com.github.spotbugs' version '6.0.2'
}

spotbugs {
    toolVersion = '4.8.1'
    effort = 'max'  // Max analysis depth (slow but thorough)
    reportLevel = 'medium'  // Report: high, medium, low priority bugs
    ignoreFailures = false  // Fail build on bugs
}

spotbugsMain {
    reports {
        xml.required = true
        html.required = true
    }
}

dependencies {
    // Additional bug detectors
    spotbugs 'com.h3xstream.findsecbugs:findsecbugs-plugin:1.12.0'
}

Bug Categories​

SpotBugs organizes detections into categories by severity and type:

  • Correctness (red flags): Null pointer dereferences, impossible casts, infinite loops, incorrect API usage
  • Dodgy code (code smells): Redundant null checks, useless control flow, suspicious comparisons
  • Performance: Inefficient string concatenation in loops, unnecessary object creation
  • Multithreaded correctness: Race conditions, inconsistent synchronization, volatile usage
  • Security: SQL injection, path traversal, insecure random number generation

Each bug has a priority (high, medium, low) indicating its severity. High-priority bugs are almost certainly real issues; low-priority bugs might be false positives or minor concerns. Configure reportLevel to control which priorities cause build failures.

Suppressing False Positives​

Sometimes SpotBugs reports issues that aren't real problems in your specific context. Suppress these with @SuppressFBWarnings, always providing justification:

// GOOD: Suppress with justification and narrow scope
public class PaymentProcessor {
    @SuppressFBWarnings(
        value = "NP_NULL_ON_SOME_PATH",
        justification = "Validated by schema prior to this method call"
    )
    public void process(Payment payment) {
        // SpotBugs thinks payment.customer might be null
        // But schema validation ensures it's non-null here
        String customerId = payment.customer.id;
    }
}

// BAD: Suppressing without justification
@SuppressFBWarnings("NP_NULL_ON_SOME_PATH")  // Why?

Document suppressions so future maintainers understand why the warning was suppressed. Link to tickets or documentation explaining the context. Review suppressions periodically - code changes might make them obsolete.

PMD for Code Quality​

PMD detects poor coding practices, suboptimal patterns, and potential bugs through source code analysis. While SpotBugs analyzes bytecode, PMD analyzes source code and can detect higher-level issues like unused variables, empty blocks, overcomplicated boolean expressions, and violations of best practices.

PMD's Focus​

PMD's strength is detecting code smells and anti-patterns before they become bugs. It's particularly good at finding:

  • Dead code (unused private methods, fields, parameters, local variables)
  • Empty blocks (empty catch blocks, empty if statements)
  • Overcomplicated expressions (unnecessary parentheses, redundant if statements)
  • Poor naming (single-letter variables except loop counters, misleading names)
  • Suboptimal patterns (using StringBuffer instead of StringBuilder, inefficient loops)

PMD rules are organized by category (best practices, code style, design, error prone, performance, security). Each category contains dozens of rules that can be enabled or disabled based on your team's standards.

Configuration​

// build.gradle
plugins {
    id 'pmd'
}

pmd {
    toolVersion = '7.0.0'
    consoleOutput = true
    ruleSets = []  // Clear default rulesets
    ruleSetFiles = files("${project.rootDir}/config/pmd/ruleset.xml")
    ignoreFailures = false
}

pmdMain {
    reports {
        xml.required = true
        html.required = true
    }
}

Sample PMD Ruleset​

<?xml version="1.0"?>
<ruleset name="Custom Rules">
    <!-- Best practices -->
    <rule ref="category/java/bestpractices.xml">
        <exclude name="GuardLogStatement"/>  <!-- Exclude if you don't use guards -->
    </rule>

    <!-- Code style -->
    <rule ref="category/java/codestyle.xml/ShortVariable">
        <properties>
            <property name="minimum" value="2"/>  <!-- Variable names min 2 chars -->
        </properties>
    </rule>

    <!-- Design rules -->
    <rule ref="category/java/design.xml">
        <exclude name="LawOfDemeter"/>  <!-- Too strict for some cases -->
    </rule>

    <!-- Error prone patterns -->
    <rule ref="category/java/errorprone.xml"/>

    <!-- Performance -->
    <rule ref="category/java/performance.xml"/>

    <!-- Security -->
    <rule ref="category/java/security.xml"/>
</ruleset>

PMD rulesets are highly customizable. Start with a comprehensive ruleset, then exclude rules that don't fit your team's style. Document excluded rules and the reasoning behind exclusions - this helps new team members understand your standards.

For comprehensive code quality metrics including cyclomatic complexity and maintainability index, see our Code Quality Metrics guide.

SonarQube for Continuous Inspection​

SonarQube provides continuous code quality inspection with a centralized dashboard showing technical debt, code smells, bugs, security vulnerabilities, and test coverage. Unlike other tools which run locally or in CI, SonarQube maintains a historical view of code quality, tracking improvements or degradations over time.

Key Capabilities​

SonarQube offers several unique capabilities:

  • Quality Gates: Define pass/fail criteria (e.g., "no new critical bugs", "maintain 80% coverage"). PRs that don't meet quality gate criteria cannot merge.
  • Technical Debt: Calculates estimated time to fix all issues, helping prioritize remediation work
  • Trend Analysis: Tracks quality metrics over time across branches, visualizing whether code quality is improving or degrading
  • Security Hotspots: Identifies security-sensitive code requiring manual review (areas where developers should verify security assumptions)
  • Duplication Detection: Finds copy-pasted code, enabling refactoring opportunities

SonarQube integrates with your CI pipeline and stores results in a central database, making quality metrics visible to the entire team. This transparency encourages quality-focused development.

Configuration​

// build.gradle
plugins {
    id 'org.sonarqube' version '4.4.1.3373'
    id 'jacoco'  // For test coverage reporting
}

sonar {
    properties {
        property 'sonar.projectKey', 'my-project'
        property 'sonar.projectName', 'My Project'
        property 'sonar.host.url', 'https://sonarqube.mycompany.com'
        property 'sonar.login', System.getenv('SONAR_TOKEN')

        // Quality gate thresholds
        property 'sonar.qualitygate.wait', 'true'  // Fail build if quality gate fails

        // Coverage
        property 'sonar.coverage.jacoco.xmlReportPaths', 'build/reports/jacoco/test/jacocoTestReport.xml'

        // Exclude generated code
        property 'sonar.exclusions', '**/generated-sources/**,**/build/**'
        property 'sonar.test.exclusions', '**/test/**'
    }
}

jacoco {
    toolVersion = '0.8.11'
}

jacocoTestReport {
    reports {
        xml.required = true  // Required for SonarQube
        html.required = true
    }
}

// Run tests, generate coverage, then analyze with SonarQube
// ./gradlew test jacocoTestReport sonar

Quality Profile Configuration​

SonarQube Quality Profiles define which rules are active and at what severity:

Rule CategoryActiveSeverityExamples
BugsAllBlocker/CriticalNull pointer dereference, resource leaks
VulnerabilitiesAllBlocker/CriticalSQL injection, weak crypto
Code SmellsCuratedMajor/MinorGod classes, deep nesting, long methods
Security HotspotsAllReview RequiredSensitive data logging, insecure random
CoverageEnabledInfoLine coverage, branch coverage

Quality profiles are configured in the SonarQube UI, not in project code. This allows centralized quality standards across all projects in your organization.

Quality Gate Configuration​

Quality gates are set in the SonarQube UI and define pass/fail criteria:

New Code (most important - focuses on preventing new issues):

  • Coverage on New Code ≥ 80%
  • Duplicated Lines on New Code ≤ 3%
  • New Vulnerabilities = 0
  • New Bugs = 0
  • New Critical/Blocker Issues = 0

Overall Code:

  • Overall Coverage ≥ 70%
  • Maintainability Rating = A or B

The "new code" focus is crucial - it's unrealistic to fix all issues in legacy code, but preventing new issues keeps quality from degrading. SonarQube defines "new code" as changes since the last release or a configured time period.

Pre-commit Hooks for Fast Feedback​

Integrate linting into Git pre-commit hooks to catch issues before they're committed. This provides immediate feedback and prevents pushing code that will fail CI checks. Use lightweight, fast checks in pre-commit hooks; save comprehensive analysis for CI.

  1. Spotless formatting - Fast, auto-fixable - catches formatting issues immediately
  2. Checkstyle - Fast, catches obvious violations like missing Javadoc or naming issues
  3. Compile check - Ensures code compiles before allowing commit
  4. Unit tests (optional) - Only fast tests, skip integration tests to keep hook fast

Pre-commit hooks should run in under 30 seconds. If they're too slow, developers will bypass them with --no-verify. Focus on fast, high-value checks.

Sample Pre-commit Hook​

#!/bin/bash
# .git/hooks/pre-commit

# Run Spotless check
echo "Running Spotless check..."
./gradlew spotlessCheck
if [ $? -ne 0 ]; then
BAD:     echo " Code formatting issues detected. Run './gradlew spotlessApply' to fix."
    exit 1
fi

# Run Checkstyle
echo "Running Checkstyle..."
./gradlew checkstyleMain checkstyleTest
if [ $? -ne 0 ]; then
BAD:     echo " Checkstyle violations detected. Fix violations and try again."
    exit 1
fi

# Compile check
echo "Compiling code..."
./gradlew compileJava compileTestJava
if [ $? -ne 0 ]; then
BAD:     echo " Compilation failed. Fix errors and try again."
    exit 1
fi

GOOD: echo " Pre-commit checks passed!"
exit 0

Alternatively, use tools like Husky (via Gradle Node plugin) or pre-commit framework for more sophisticated hook management with staging area integration.

CI/CD Integration​

Static analysis must run in CI/CD pipelines to enforce quality gates. Even with pre-commit hooks, developers can bypass them (git commit --no-verify), so CI enforcement is essential. Configure pipelines to fail builds when quality thresholds aren't met - this prevents low-quality code from merging.

CI Pipeline Stages​

Organize CI into stages with increasing comprehensiveness and runtime:

1. Fast feedback (< 2 min):

  • Compile
  • Spotless check
  • Unit tests

2. Static analysis (2-5 min):

  • Checkstyle
  • PMD
  • SpotBugs

3. Comprehensive analysis (5-10 min):

  • Integration tests
  • Code coverage (JaCoCo)
  • SonarQube analysis with quality gate

This staged approach provides fast feedback for simple issues while running expensive analysis only after basic checks pass. Developers get compile errors in 2 minutes, not 10.

Sample GitLab CI Configuration​

# .gitlab-ci.yml
stages:
  - fast-feedback
  - static-analysis
  - comprehensive

compile-and-format:
  stage: fast-feedback
  script:
    - ./gradlew compileJava compileTestJava
    - ./gradlew spotlessCheck
    - ./gradlew test

checkstyle-pmd-spotbugs:
  stage: static-analysis
  script:
    - ./gradlew checkstyleMain checkstyleTest
    - ./gradlew pmdMain pmdTest
    - ./gradlew spotbugsMain
  artifacts:
    reports:
      junit: build/test-results/test/*.xml
    paths:
      - build/reports/

sonarqube:
  stage: comprehensive
  script:
    - ./gradlew test jacocoTestReport sonar
  only:
    - merge_requests
    - main

See our CI/CD Pipeline Configuration for more examples including GitHub Actions and advanced caching strategies.

Compiler Warnings as Errors​

Compiler warnings indicate potential bugs or code quality issues. Enable all warnings and treat them as errors (-Werror). This forces you to either fix the issue or explicitly suppress the warning with justification.

Why Warnings Matter​

Warnings are the compiler saying "this looks suspicious." Ignoring them leads to runtime bugs:

  • Unchecked cast warning: Indicates you're losing type safety, risking ClassCastException
  • Deprecation warning: You're using an API that may be removed, risking future breakage
  • Unused variable warning: Dead code that might indicate a logic error

When suppression is necessary (e.g., interacting with legacy code or generic type erasure), use @SuppressWarnings with the smallest possible scope and add a comment explaining why. Never ignore warnings globally or suppress them without understanding the underlying issue.

Configuration​

tasks.withType(JavaCompile) {
    options.compilerArgs << '-Xlint:all'       // Enable all warnings
    options.compilerArgs << '-Xlint:-serial'   // Disable serialVersionUID warning
    options.compilerArgs << '-Werror'          // Treat warnings as errors
}

Common Warnings​

WarningMeaningFix
Unchecked castType safety violationAdd proper generics, validate types, or suppress with justification
Unused variableDead codeRemove unused code
DeprecationUsing deprecated APIMigrate to replacement API
Raw typesMissing generic parametersAdd type parameters: List<String> not List
Unchecked callCalling generic method with raw typeAdd type arguments to method call

Suppression Examples​

// GOOD: No warnings - properly typed code
List<Payment> payments = repository.findAll();

// GOOD: Explicit suppression with narrow scope and reason
@SuppressWarnings("unchecked")  // Legacy API returns untyped collection
var list = (List<Payment>) legacyApi.getPayments();

// BAD: Ignoring warnings by using raw types
List list = (List) object;  // Unchecked cast warning ignored - type safety lost!

// BAD: Broad suppression scope
@SuppressWarnings("all")  // Never do this - suppresses ALL warnings
public class PaymentService {
    // Hides potentially serious issues
}

// GOOD: Suppress specific warnings with minimal scope
public class PaymentService {
    @SuppressWarnings("deprecation")  // Using deprecated API until migration complete
    public void processPayment(Payment payment) {
        legacyGateway.process(payment);  // Deprecated method - tracked in JIRA-1234
    }
}

Tool Comparison and Selection​

Choosing the right combination of tools depends on your project's needs, team size, and quality goals.

ToolPurposeSpeedBest ForIntegration
SpotlessCode formattingVery FastEnforcing consistent stylePre-commit, CI
CheckstyleCoding standardsFastNaming, structure, documentationPre-commit, CI
SpotBugsBug detectionMediumFinding actual bugs, security issuesCI
PMDCode qualityFast-MediumDead code, anti-patternsCI
SonarQubeComprehensive analysisSlowHistorical trends, quality gatesCI (post-merge)
Compiler warningsType safetyVery FastCatching type errorsAlways on

Minimal setup (small team, starting out):

  • Spotless (formatting)
  • Checkstyle (standards)
  • Compiler warnings as errors
  • Pre-commit hooks for fast feedback

Comprehensive setup (large team, critical code):

  • All minimal tools, plus:
  • SpotBugs (bug detection)
  • PMD (code quality)
  • SonarQube (centralized quality tracking)
  • Quality gates in CI/CD

Start with the minimal setup and add tools as your team matures. Don't overwhelm developers with too many tools at once - introduce them incrementally.

For refactoring strategies when addressing static analysis findings, see our Refactoring Guide.

Custom Rules and Team-Specific Standards​

Most static analysis tools support custom rules for team-specific or domain-specific standards. Use custom rules to enforce architectural constraints, prevent anti-patterns specific to your codebase, or codify team conventions.

When to Create Custom Rules​

Create custom rules for patterns that:

  • Recur frequently in code reviews (automate the feedback)
  • Cause production bugs (prevent them automatically)
  • Violate architectural constraints (enforce your architecture)
  • Are specific to your domain (e.g., payment processing patterns)

Don't create custom rules for one-off issues or patterns that are easily caught during code review. Custom rules require maintenance and add complexity - use them judiciously.

Examples of Custom Rules​

  • Architectural constraints: "Services must not depend on controllers"
  • Domain rules: "Payment amounts must use BigDecimal, never double/float"
  • Security: "All database queries must use PreparedStatement, never string concatenation"
  • Testing: "Test methods must follow naming pattern: test_<scenario>_<expectedBehavior>"

Checkstyle Custom Rule​

<!-- Enforce that @Transactional is not used on interface methods -->
<module name="AnnotationLocation">
    <property name="allowSamelineMultipleAnnotations" value="false"/>
    <property name="allowSamelineSingleParameterlessAnnotation" value="false"/>
    <property name="tokens" value="INTERFACE_DEF"/>
</module>

PMD Custom Rule (XPath)​

<!-- Detect usage of System.out.println (should use logging framework) -->
<rule name="NoSystemOutPrintln" language="java"
      message="Use logging framework instead of System.out.println"
      class="net.sourceforge.pmd.lang.rule.XPathRule">
    <description>System.out.println should not be used in production code</description>
    <priority>2</priority>
    <properties>
        <property name="xpath">
            <value>//PrimaryPrefix/Name[@Image='System.out.println']</value>
        </property>
    </properties>
</rule>

Document custom rules in your team's coding standards and provide rationale. Custom rules should be reviewed and approved by the team, not imposed unilaterally - buy-in ensures compliance.

Further Reading​

Internal Documentation​

External Resources​

Summary​

Key Takeaways​

  1. Automated formatting - Use Spotless to eliminate formatting debates
  2. Multi-layered analysis - Combine Checkstyle, SpotBugs, and PMD for comprehensive coverage
  3. Early feedback - Pre-commit hooks catch issues before they enter the repository
  4. CI enforcement - Quality gates in CI/CD prevent low-quality code from merging
  5. Compiler warnings - Treat all warnings as errors
  6. Tool selection - Start minimal, add tools as team matures
  7. Custom rules - Enforce team-specific standards automatically
  8. SonarQube - Track quality trends over time
  9. Documented suppressions - Always justify why warnings are suppressed
  10. Integration - Make linting part of the development workflow, not an afterthought

Next Steps: Configure these tools in your project, integrate them into CI/CD pipelines, and review the Refactoring Guide for strategies to address findings.