I had never used a linter before taking a software development class. At first I liked it because it caught simple mistakes and made them easy to fix. During a merge, though, it rejected the change because there was one missing blank line between pieces of code. Fixing it took only a few seconds, but I still had to request another review just to add a newline. Is this normal in professional development, or are linters usually configured so formatting issues are fixed automatically before code reaches the merge stage?
4 Answers
Formatting rules may feel petty, but consistent style prevents endless arguments about spaces, braces, and blank lines and makes large codebases easier to read. The best experience is to choose the rules once, configure the editor to apply them automatically, and treat the formatter as part of the normal development workflow rather than as a surprise gate at merge time.
A common setup is a pre-commit hook that runs the formatter and linter locally, followed by the same checks in CI. If CI fails, the merge is blocked, but ideally the developer finds out before opening a review. Some teams also configure formatting-only fixes so they do not require another human review.
The exact behavior depends on the language and toolchain. Linters are often run by the editor, as part of the test suite, and again in CI. Blocking a merge is intentional because the main branch should always pass its automated checks, but the workflow should make trivial fixes automatic or catch them before review.
Linters are usually integrated much earlier than the merge. Editors can run them on save, and formatters can automatically fix things like indentation, spacing, and blank lines. That way the code is normally clean before it is committed or pushed.
That is what I expected. In this class, the formatting failure blocked the merge and forced a fresh review, even though nobody had to reconsider the actual code.