If a blank line can block your merge, that is a config bug, not a discipline problem

A post on dev.to by denlava describes a familiar failure mode: code that works and passes its tests has its merge blocked because the linter found a missing blank line, forcing a second review cycle for what the author calls a three-second fix ^[1]. It is worth attention not because the anecdote is new but because every element of that outcome was chosen by somebody in a configuration file.

The mechanism is dull. Linters check code against predefined rules spanning everything from critical syntax errors to minor formatting quirks ^[2], and the gate wired into the version control system asks one boolean question before allowing a merge: did anything fail ^[4]. When the tool treats all violations as critical regardless of their impact on functionality ^[3], that boolean flattens a missing semicolon and a missing newline into the same consequence: the developer edits, resubmits, and waits for review again ^[5]. The post names two compounding failures, the absence of tiered rules and a review process that fires for any change regardless of size ^[7].

The prescription is the right shape. Tier the rules so a missing semicolon blocks the merge while a missing blank line surfaces as a warning ^[9], and automate the trivial fixes so whitespace never reaches a human, with a formatter such as Prettier running on save ^[8].

I would push the second half further than the post does. Formatting on save is a promise about developer machines, which means it holds only as long as every contributor has the plugin installed and configured identically. The load-bearing place for a formatter is the pipeline itself: run it, and if it rewrites the file, the rewrite is the output. A rule that a machine can satisfy without judgement should never be delivered to a person as a line number.

Then there is ownership of the config. The post observes that rules are often inherited from a previous project or team that the current team does not actually prioritise ^[6], and recommends reviewing configurations periodically against team priorities, since a small internal project and a large-scale application do not need the same standard ^[10][11]. Inherited config is the tell. If nobody can name the person who set a rule to error rather than warn, it is not a standard, it is sediment, and it is still spending review cycles every week.

The post also argues for educating new developers on the rationale behind rules so they are less likely to feel bullied by the linter ^[12]. Education is fine, but it is not a substitute for automation: a rule that has to be explained to every new hire in order to be tolerable is a rule that should be applied by a machine, not defended in a code review.

One caveat on the source. This is a single opinion post; it reports no measurement of how often merges are blocked on formatting, no team size, and no named organisation ^[13]. The argument holds on its own logic rather than on evidence, and the four remedies it offers are all cheap to test locally ^[14].

Worth checking this week: pull the last month of blocked merges and group them by rule ID, then look at how many of those rules have an auto-fix. Check whether your lint configuration uses a severity field at all, and whether the formatter runs in CI or only in editors. If it runs only in editors, you are enforcing a standard you have not automated, and reviewers are absorbing the difference.