## TL;DR

A line exceeds the configured `LineLength` maximum (commonly 120). Wrap the statement, extract a variable to shorten it, or raise the limit in `checkstyle.xml` if the team agrees.

## Error

```text
[ERROR] src/main/java/com/acme/Order.java:42: Line is longer than 120 characters (found 137).
```

## Steps

1. Reproduce: run `mvn checkstyle:check` or the Gradle checkstyle task locally. Expected: the same file/line report as the PR.
2. Wrap the line: break method chains, extract a local variable for a long expression, or split string concatenation. Expected: the line is within the limit.
3. For unwrappable lines (long URLs in comments), add a targeted suppression for that line. Expected: the build passes with the suppression documented.
4. Re-run the checkstyle task. Expected: BUILD SUCCESSFUL.

## When to use

- Checkstyle reports `Line is longer than N characters` and the build fails.
- The limit comes from the project's checkstyle.xml.

## When not to use

- A different Checkstyle module fails (e.g. UnusedImports)  -  fix that module instead.
- The file is generated; exclude it in the checkstyle config rather than editing it.

## Tool compatibility

- Checkstyle 8.x/10.x via Maven or Gradle plugin.
- Java 8+.

## Variant phrasings

### LineLength in test sources

Many projects use a separate, higher limit for tests via a second checkstyle execution.

### Suppression not working

The suppression filter needs the `SuppressionFilter` module wired in checkstyle.xml.

## Why it happens

LineLength keeps code reviewable in standard-width views and consistent diffs. Checkstyle binds the check to the build, so any violation fails compilation-phase gates.

## Edge cases

- Extracting a variable just to shorten a line is fine; extracting nonsense names to game the count is not.
- Comments and annotations count toward the length too.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v3N2-YjTmHGf5KTWYpTTLA