# Critique of Enforced Automated Code Formatters

DevFeed: [Critique of Enforced Automated Code Formatters](<https://devfeed.tech/articles/acab-fire-the-code-style-cop-in-your-head-30457.md>)

Original publisher: [Read original article](<https://dev.to/autonomousapps/acab-fire-the-code-style-cop-in-your-head-m8b>)

Author: Tony Robalik

Published: 2024-09-29T18:47:32Z

Content type: opinion

Language: en

Sources: [DEV Community: Tony Robalik](<https://devfeed.tech/sources/dev-community-tony-robalik.md>)

Topics: [formatting](<https://devfeed.tech/topics/formatting.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [IntelliJ IDEA](<https://devfeed.tech/topics/intellij-idea.md>)

Tags: [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [intellij-idea](<https://devfeed.tech/tags/intellij-idea.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

An opinion piece arguing against enforced automated code formatters, especially in the author's Kotlin, Gradle, and IntelliJ IDEA workflow. It distinguishes formatting enforcement from linting and questions whether consistent whitespace alone improves readability, maintainability, flow, or error prevention.

## Source excerpt

Photo by Karsten Winegeart on Unsplash Let's get something out of the way right at the start: I hate enforced automated code style formatters. This post started because I had an axe to grind, and I made the ill-advised decision to haul my grindstone out into the public square. Multiple times. Over weeks. Disclaimer! I primarily write Kotlin code that I build with Gradle, in Intellij IDEA (in order of importance). Since many of my complaints are about specific implementation-level issues with code style formatting tools, if you don't also build Kotlin with Gradle, don't worry about it! I'm just an internet crank and you are relieved from the duty of telling me how wrong I am. Second disclaimer! Enforced code style is not the same thing as linting for usage issues. I like linters! Please tell me I forgot to close a stream, or am calling a Java API with ambiguous nullability. Ok, let's gooooo. Arguments in favor of enforcement of consistent code style Consistent code style is better than inconsistent code style Sure. But what do we mean by better? The general claims are: More readable More maintainable Aids with achieving flow Contains fewer errors I think we've already run into an issue, which is we need to clarify what "style" means. Are we just talking about where we break lines and how long those lines are? Or do we mean something deeper? If we are talking about line breaks, I think the argument is pretty weak. Sure, all else being equal, if two pieces of source code follow the same general style, I will have an easier time with pattern-matching and "understanding" them. But what if my pattern-matching misleads me? What if I gloss over the fact that two structurally-identical blocks contain a single semantic difference that entirely changes the behavior? Maybe that single difference is easier to spot if the whitespace is identical, or maybe it's easier to miss because my brain too-readily dismisses the second block as identical to the first. This is actually what c