As someone using formating tools on IDE since the 1990's and UNIX indent as well, I really don't get the hype for formatters.

Even moreso in the LLM age of tooling and coding agents.

▲

jillesvangurp 4 days ago | parent [-]

It's a minor issues in teams where people use inconsistent formatting. This causes needless complications when merging code and additional work related to resolving conflicts that shouldn't exist to begin with.

Some languages (Go, Rust) have essentially solved this issue to the point where blindly running the formatters these languages have solves the problem and is uncontroversial.

Sadly, the language of choice for me (Kotlin) has a big unaddressed problem here where what the IDE does for formatting and what independent formatting tools do are two things that are hard to align for mostly the historical reasons that what the IDE does is fragmented over different bits of code that don't listen to the same configuration. There is a lot of variation in preferences for indentation, where to put new lines, line length, what order to put imports in, which imports to use wildcards for (if any at all), etc. Particularly imports are a problem because the bit of code that organizes imports is separate from the bit of code that formats code in the IDE.

The common solution of using IDE plugins to work around this is a bit of a kludge. The proper solution would be a more sane way to just make the IDE externally configurable so that build tools can make the IDE do exactly the same as what they do without requiring users to manually configure their IDEs just right by installing plugins or fiddling with configuration. This stuff should not be user controllable if there is a build file that defines the proper formatting.

Coding agents actually add to this problem. Because getting those to stick to formatting conventions is tricky. Unless you have tools that just fix that properly.

So good change in uv and probably something I'd be using on my next python project (I do those once in a while).

▲

pjmlp 4 days ago | parent [-]

Easily solvable with SCM pre-commit hooks, at very least since CVS days.

All major IDEs allow to save the format configurations, which can be stored on the repo alongside the code as the team official's configuration.

Coding agents solve this problem in that eventually all programming languages will be as relevant as mastering Assembly is nowadays.

I already do stuff in low code/no code, that in the past I would be manually writing code to sort out those issues.

In the meantime, you can also ask them to format generated code in whatever way one feels like it.

▲

jillesvangurp 4 days ago | parent [-]

That's exactly what I mean by kludge. And this attitude is exactly the problem and reason why most languages continue to do the wrong thing here.

Your solution requires user discipline and fiddling with things that should just work right without fiddling. And it needs to happen on every development environment. You can't really enforce it except via annoying additional kludges in the form of failing builds.

I've never been on a team where this was done right. I've been on plenty of teams with convoluted half enforced formatting rules (and thousands of violations).

I know how to fix it for my own code. But being able to force everyone I have to work with to do the same thing over and over again is the problem that needs solving. Everybody just shrugs it off and does nothing about it. What are you going to do. It's always been this miserable this way. Industry wide apathy on this topic.

That's why I appreciate what Google did with Go here so much. Not a fan of the language necessarily. But they did the right thing with making code formatting not optional and a compile error to skip. Stuff like this should not be a debate or discussion or a follow this 20 step process to setup your work environment properly but just something that works right (for fuzzy definitions of right) as specified by the build file in the code repository.

It's a minor annoyance that I wish Jetbrains would just take more serious.

	▲	pjmlp 4 days ago \| parent [-]
		DevOps are the disciple that tames the developer team malpractices, it doesn't stop at formating, static analysis, misbehaved dependencies taken directly out of Internet without IT approval, no proper security workflows, there is no need for user disciple with manual steps.